All my amd64 problems appear to be KSE

[Sean McNeil]

On Sat, 2004-06-05 at 09:57, Daniel Eischen wrote:
> On Sat, 5 Jun 2004, Sean McNeil wrote:
> 
> > On Sat, 2004-06-05 at 09:16, Daniel Eischen wrote:
> > > 
> > > I would also make sure that libkse isn't being used (either
> > > remove it from your system or use libmap.conf).  I would think
> > > that trying to use libc_r and libkse together would present
> > > the same sort of problem as using libpthread and libkse
> > > together, but just to be sure...
> > 
> > There hasn't been a libkse on my system in a very long time.  Just to
> > make sure, I have searched the whole computer and it was not found. 
> > Also, I have done the libmap.conf of libc_r:
> > 
> > libc_r.so.5                    libpthread.so.1
> > libc_r.so                      libpthread.so.1
> > 
> > I can now claim that I am no_one without a doubt.  I got the same
> > failures as before.
> > 
> > With regards to gnome-specific or if KDE has the same issue, I cannot
> > answer.  I do not use KDE.  It would appear to be gnome-specific
> > (gtk-specific?).  Emacs has never given me any problems, but neither has
> 
> That includes glib also, right?

right.

> > nautilus, the panel, or a number of other gnome applications.
> > 
> > For the moment, I highly suspect this is a pthread/readline interaction
> > causing the crashes.
> 
> Why do you suspect that?

I suspect libreadline because the only time I get a crash is when I type
in a character to an application or when it is starting up (resize?). 
Sorry, it just occurred to me that this might be useful information.

Looking at my bash problem, I can see there is an issue with any program
that might get a signal and then want to call an older installed handler
as

sa_handler(sig)

What happens is that sigaction is called and returns a context with the
_thr_sig_handler function.  So the new signal handler is called and then
it in turn wants to call the old one.  But the old handler isn't called
as a sigaction.

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?

Why doesn't this show an issue in i386?  Is it just luck that info has
been null and not caused a bad dereference?

Sean