From: Bart Schaefer <schaefer@brasslantern.com>
To: zsh-workers@sunsite.dk (Zsh hackers list)
Subject: Re: PATCH: Seg. fault in chpwd hook in a widget
Date: Mon, 09 Mar 2009 08:49:36 -0700 [thread overview]
Message-ID: <090309084936.ZM27146@torch.brasslantern.com> (raw)
In-Reply-To: <17095.1236597765@csr.com>
On Mar 9, 11:22am, Peter Stephenson wrote:
} Subject: PATCH: Seg. fault in chpwd hook in a widget
}
} Just had a look at the Sourforge bug tracker, which normally I don't
} have time to do (please feel free to forward things to the list if you
} notice anything there which appears to be reproducible and hasn't been
} fixed); issue 2338948 is this:
This was originally on zsh-workers, thread starting at 26089. You even
answered with a patch in 26091, which was applied 2008-11-25 or so says
the ChangeLog, but you followed *that* by saying it might need deeper
inspection.
} This is an interesting interaction of different levels of the shell. I
} think a key part of it is the "source". It seems that hbegin() in here
} is trashing the current history line chline. It seems to me that we
} should only be calling hbegin() after a lexsave(), to protect against
} this, and there appears to be nothing in the call to loop() from
} source() that does that.
I think you're right about lexsave(), although history has never really
been my bit of the code [to the extent that I "have" any bit at all].
Wayne may have some input.
} I'm quite surpsised we've never seen anything like this before; there
} seems to be no protection against chline being trashed by any old
} "source" or "." that comes along. As far as I can see, lexsave() is the
} only way of doing this. I think the answer is that most of the time the
} history mechanism has exited by this time, so chline is already NULL and
} its friends aren't being used.
So why *hasn't* the history mechanism exited by the time chpwd is
called? Aha; it's not direclty because of "source", it's because he's
calling "cd" from inside a ZLE widget. The hooks are invoked in a
context from which they were never meant to be invoked.
So your lexsave()/lexrestore() is probably the correct thing, but there
may be other consequences of hook/widget interaction still waiting to
bite us for other hooks.
} Obviously any alternative opinions would be useful. Currently that
} means Bart, but both of us would be very interested in getting new
} apprentice source code gurus...
Leak some of that sentiment onto zsh-users. Maybe potential apprentices
just aren't reading -workers.
next prev parent reply other threads:[~2009-03-09 15:50 UTC|newest]
Thread overview: 3+ messages / expand[flat|nested] mbox.gz Atom feed top
2009-03-09 11:22 Peter Stephenson
2009-03-09 15:49 ` Bart Schaefer [this message]
2009-03-09 16:02 ` Peter Stephenson
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=090309084936.ZM27146@torch.brasslantern.com \
--to=schaefer@brasslantern.com \
--cc=zsh-workers@sunsite.dk \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
Code repositories for project(s) associated with this public inbox
https://git.vuxu.org/mirror/zsh/
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).