zsh-workers
 help / color / mirror / code / Atom feed
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.


  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).