All my amd64 problems appear to be KSE
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
More information about the freebsd-threads