From: Alexandre Oliva (oliva@dcc.unicamp.br)
Date: Sat Feb 06 1999 - 23:10:47 EST
On Feb 5, 1999, Godmar Back <gback@cs.utah.edu> wrote:
> Where could a pattern like this (numbers increasing by 16) come from?
Maybe from the uninitialized jump table, before the relocator fixes it
up.
> So, the question is: is this a bug in ld.so?
I doubt it. But it might be a problem in the signal dispatcher; if it
doesn't save/restore registers properly, we might observe this kind of
problem. But it would be very surprising if both Solaris' and Linux'
dispatchers were broken...
> And why does it only happen when SIGVTALRM is enabled *and* unblocks
> the signals from with the handler? Is it because ld.so's routines are
> not async-signal-safe?
That should only be a problem if we actually context-switched or
called some library function from within the signal handler, but we
apparently don't. Unless dlopen modifies some global symbol table in
a way that calling unrelated code may crash. In this case, we'd have
to block signals before dlopening anything. This would probably be a
good idea in general. Is blocking signals part of the threading API?
--
Alexandre Oliva http://www.dcc.unicamp.br/~oliva aoliva@{acm.org}
oliva@{dcc.unicamp.br,gnu.org,egcs.cygnus.com,samba.org}
Universidade Estadual de Campinas, SP, Brasil
This archive was generated by hypermail 2b29 : Sat Sep 23 2000 - 19:57:59 EDT