|
From: <ar...@de...> - 2004-02-02 15:41:18
|
Tom Hughes <th...@cy...> writes: > ------- You are receiving this mail because: ------- > You are the assignee for the bug, or are watching the assignee. > You reported the bug, or are watching the reporter. > You are on the CC list for the bug, or are watching someone who is. > > http://bugs.kde.org/show_bug.cgi?id=74016 > > > > > ------- Additional Comments From th...@cy... 2004-02-02 16:05 ------- > Subject: Re: New: corrupt stack on tkill syscall wrapper > > In message <200...@kt...> > ar...@de... wrote: > >> Running gdb under valgrind I get this core dump: >> >> (gdb) bt >> #0 0x40194c3a in vgPlain_do_syscall () from /usr/lib/valgrind/valgrind.so >> #1 0x4017691f in vgPlain_ktkill (tid=1075674952, signo=22208) at vg_mylibc.c: >> 207 >> Previous frame inner to this frame (corrupt stack?) >> >> It looks like some bit of the tkill syscall wrapper is broken. > > We're going to need a bit more information than that - can you compile > valgrind with debugging so you can actually see where in do_syscall it > is failing? > > You've shown us the backtrace, but what actually happened to valgrind > at that point? Presumably it died with a signal, but which one? Segfault. > > Those tid and signo values in the arguments to ktkill look pretty > implausible as well, or was the stack corrupted or something? The stack wasn't corrupted, but GDB's backtraces have never worked well for valgrind's syscall wrapper. > > What was the code trying to do anyway? What signal was it trying to > send and where had it got the TID to send it to from? This is GDB. It was probably trying to send a SIGSTOP to a thread... Wait, I apologize, it is not actually related to tkill. It looks like valgrind called its own tkill wrapper to cause a SIGSEGV. Here's the output from just before: ==9356== ==9356== Invalid read of size 4 ==9356== at 0x403BD643: __GI_tcsetattr (tcsetattr.c:74) ==9356== by 0x812B05F: (within /usr/bin/gdb) ==9356== by 0x81149A8: serial_set_tty_state (in /usr/bin/gdb) ==9356== by 0x8122423: terminal_inferior (in /usr/bin/gdb) ==9356== Address 0x0 is not stack'd, malloc'd or free'd ==9356== ==9356== Process terminating with default action of signal 11 (SIGSEGV): dumping core ==9356== Address not mapped to object at address 0x0 ==9356== at 0x403BD643: __GI_tcsetattr (tcsetattr.c:74) ==9356== by 0x812B05F: (within /usr/bin/gdb) ==9356== by 0x81149A8: serial_set_tty_state (in /usr/bin/gdb) ==9356== by 0x8122423: terminal_inferior (in /usr/bin/gdb) ==9356== ==9356== ERROR SUMMARY: 20 errors from 6 contexts (suppressed: 7 from 2) ==9356== malloc/free: in use at exit: 375692 bytes in 2638 blocks. ==9356== malloc/free: 3317 allocs, 679 frees, 447506 bytes allocated. ==9356== For a detailed leak analysis, rerun with: --leak-check=yes ==9356== For counts of detected errors, rerun with: -v zsh: segmentation fault (core dumped) valgrind gdb ./a.out Just run a trivial binary inside the GDB in unstable to reproduce, it segfaults immediately after "run". I don't believe there is anything wrong with the tcsetattr call. Because GDB can't backtrace through valgrind nowadays I can't figure out much more. > > Tom -- Andrés Roldán <ar...@de...> GPG Key-ID: 0xB29396EB http://people.fluidsignal.com/~aroldan |