All my amd64 problems appear to be KSE

Sean McNeil sean at mcneil.com
Wed Jun 9 11:21:41 GMT 2004


On Sat, 2004-06-05 at 12:41, Marcel Moolenaar wrote:
> On Sat, Jun 05, 2004 at 03:21:29PM -0400, Daniel Eischen wrote:
> > > 
> > > I suppose it is really libreadline at fault here and it should check
> > > SA_SIGINFO.  Do you think there might be others that don't check either?
> > 
> > I don't know; perhaps.
> > 
> > > Why doesn't this show an issue in i386?  Is it just luck that info has
> > > been null and not caused a bad dereference?
> > 
> > When I write signal handlers, I usually check info and ucp to
> > make sure they are not null before using them.  Actually, I
> > rarely use them anyways so it doesn't matter if they are null
> > or not.
> 
> Nevertheless, libpthread has a signal handler that takes 3 arguments
> and it apparently gets called from other signal handlers (chaining)
> that do not always pass along the full context; just the signal number
> in this case. Consequently, info and ucp can be garbage as is the case
> here. This is a general problem and potentionally causes failures on
> all platforms, not just amd64. 
> 
> I tend to give blame to libreadline here, but I don't have a clear or
> even complete picture of it all, so I might actually miss a vital
> precondition that's being violated and that would clear libreadline...

This really isn't libreadline's fault, but it is an issue.  They should
check to see if the signal hander/action has SA_SIGINFO.  The problem I
saw should never have happened.  It came about because of a symbol
binding issue.  Removing an incorrect usage of libpthread by libdb41
resolved the issue.

In the long run, it would be nice to fix this as there may be a time
when someone installs an SA_SIGINFO handler before libreadline is
initialized.

Cheers,
Sean




More information about the freebsd-amd64 mailing list