From 47e4d194dc36adfcfd2577fa4630c9fcded005d3 Mon Sep 17 00:00:00 2001 From: Thomas Schwinge Date: Sun, 27 Oct 2013 19:15:06 +0100 Subject: IRC. --- open_issues/gdb_signal_handler.mdwn | 71 +++++++++++++++++++++++++++++++++++++ 1 file changed, 71 insertions(+) (limited to 'open_issues/gdb_signal_handler.mdwn') diff --git a/open_issues/gdb_signal_handler.mdwn b/open_issues/gdb_signal_handler.mdwn index 3084f7e3..5e27a099 100644 --- a/open_issues/gdb_signal_handler.mdwn +++ b/open_issues/gdb_signal_handler.mdwn @@ -401,3 +401,74 @@ License|/fdl]]."]]"""]] braunr: are you sure? there is minimal user-code run before the signal is going into the handler. you "step out of the handler" + + +# IRC, freenode, #hurd, 2013-10-24 + + how come some executables are not debuggable with gdb, e.g Cannot + access memory at address xxx. -fPIC flag? + no + i'm not sure but it's certainly not -fPIC + Another example is localedef: ./debian/tmp-libc/usr/bin/localedef + -i en_GB -c -f UTF-8 -A /usr/share/locale/locale.alias en_GB.UTF-8 + segfailts + and in gdb hangs after creating a thread., after C-c no useful + info: stack ends with: Cannot access memory at address 0x8382c385 + if it's on the stack, it's probably a stack corruption + gnu_srs: are u using 'x' command or 'print' in GDB? IIRC + print may throw such message, but x may not + bt + x may too + what you're showing looks like an utf-8 string + c385 is Å + 83 is a special f + 82 is a comma + so the stack is corrupted:-( + probably + well, certainly + but gdb should show you where the program counter is + is that: ECX: the count register + no + eip + program counter == instruction pointer + k!, the program counter is at first entry in bt: #0 0x01082612 + in _hurd_intr_rpc_msg_in_trap () at intr-msg.c:133 + this is the hurd interruptible version of mach_msg + so it probably means the corruption was made by a signal handler + which is one of the reasons why gdb can't handle Ctrl-c + what to do in such a case, follow the source code + single-stepping? + single stepping also uses signals + and using printf will probably create an infinite recursion + in those cases, i use mach_print + as a first step, you could make sure a signal is actually received + and which one + hmm + also, before rushing into conclusions, make sure you're looking at + the right thread + i don't expect localedef to be multithreaded + but gdb sometimes just doesn't get the thread where the segfault + actually occurred + two threads: 1095.4 and 1095.5 (created when starting localedef + in gdb) + no, at the time of the crash + the second thread is always the signal thread + OK,in gdb the program hangs, interrupted by C-c, outside it + segfaults + when you use bt to get the corrupted stack, you can also use info + threads and thread apply all bt + I did: http://paste.debian.net/61170/ + ok so it confirms there is only one real application thread, the + main one + and that the corruption probably occurs during signal handling + rpctrace (edited out non-printable characters): + http://paste.debian.net/61178/ + Ah, have to do it again as root;-) + yes .. :p + new last part: http://paste.debian.net/61181/ + so, there is a seek, then a stat, then a close perhaps (port + deallocation) and then a signal received (probably sigsegv) + gnu_srs: when you try running it in gdb, do you get a sigkill ? + damn, gdb on darnassus is bugged :-( + It hangs, interrupted with C-c. + ok -- cgit v1.2.3