Harold Gutch <logix@foobar.franken.de> writes:

> #0  0x0048a3b6 in ap_sys_siglist ()
> (gdb) where
> #0  0x0048a3b6 in ap_sys_siglist ()
>
>   This is strange - ap_sys_siglist isn't a function, but an
>   array of 32 char-pointers, defined in http_main.c:
>
>   #define NumSIG 32
>   const char *ap_sys_siglist[NumSIG];

Yes.  This is why you got the segfault:  Since this is data and not
code the page does not have execute permission set.


> #1  0x204b484a in __umoddi3 () from /usr/lib/libgcc_s.so.1

Now, __umoddi3 has no calls to ap_sys_siglist of course.  It does call
a couple of other libgcc functions though, for example ___lshrsi3.
The thing is, these functions sometimes have nonstandard calling
conventions which may interfere with the dynamic linker.  My guess is
that this is what has happened here.  libgcc_s.so is pure evil.


  // Marcus