SIGSEGV in *__GI_putwc (wc=84, fp=0x804b040) at putwc.c:31

[Martin Schlemmer <azarah at nosferatu dot za dot org>]

Hi

We have a sandbox that verify that all writes stay in the sandbox.

With cvs 20040619 (and prob earlier?) of glibc the libio/tst_putwc
keeps on segfaulting during 'make check'.  Trace follows:

---
Program received signal SIGSEGV, Segmentation fault.
0x4005ec9f in *__GI_putwc (wc=84, fp=0x804b040) at putwc.c:31
31        result = _IO_putwc_unlocked (wc, fp);
(gdb) bt
#0  0x4005ec9f in *__GI_putwc (wc=84, fp=0x804b040) at putwc.c:31
#1  0x08049145 in do_test ()
#2  0x0804b040 in ?? ()
#3  0x00000001 in ?? ()
#4  0x00000000 in ?? ()
#5  0x00000001 in ?? ()
#6  0xffffffff in ?? ()
#7  0x4011385c in __elf_set___libc_thread_subfreeres_element___rpc_thread_destroy__ ()
   from /space/var/tmp/portage/glibc-2.3.4.20040619/work/build/libc.so.6
#8  0xbfffda08 in ?? ()
#9  0x4011385c in __elf_set___libc_thread_subfreeres_element___rpc_thread_destroy__ ()
   from /space/var/tmp/portage/glibc-2.3.4.20040619/work/build/libc.so.6
#10 0x00000000 in ?? ()
#11 0x400b3e64 in *__GI___sbrk (increment=-1073751100) at ../sysdeps/generic/sbrk.c:34
Previous frame inner to this frame (corrupt stack?)
(gdb)
---

The whole glibc is compiled with -ggdb, so I assume the 'untraced' calls
is from the libsandbox.so that gets preloaded.  Now:

1)  Anybody seen anything like this before, or can think of anything
that might be related?  I guess it might be stack corruption on the
side of libsandbox.so, but it have been working for months unchanged,
and this is pretty much the first of its kind.

2)  If not 1), is there a way to get gdb to also trace into the
preloaded libsandbox.so?

NB: Please keep me in CC


Thanks,
-- 
Martin Schlemmer

Attachment: signature.asc
Description: This is a digitally signed message part