At 2007-06-27T09:02:04+1200, Kerry Mayes wrote: > There is an annoying bug in evolution that I reported but can't get to do > it when I have the debugger going. The debug team have told me that you > can "attach the debugger when it has frozen" but I don't know how to do > that and can't find an appropriate reference.
The official documentation for GDB is here: http://sourceware.org/gdb/documentation/ There are also plenty of basic tutorials around to get you started with using it. Here's the basic crash course I usually give people: 0. It might be useful to install the debuginfo packages for Evolution and the libraries it uses. They should be available from your distro's package repository as separate packages with names like libfoo-debuginfo. Without these, the details available via GDB will be somewhat limited, but might be enough for the developers to track down the problem. 1. Reproduce the hang. 2. Attach to the hung Evolution process with GDB: a. Find the process ID: % pgrep evolution 12345 b. Attach with the debugger: % gdb -p 12345 c. Produce a backtrace for all threads: (gdb) thread apply all backtrace You might want to specify 'full' after 'backtrace' to get the values of local variables. d. Detach from the process and quit GDB: (gdb) quit The program is running. Quit anyway (and detach it)? (y or n) y Depending on the stack depth and the number of threads, the output may be too large to cut and paste from your console easily. One solution to that is to run gdb in batch mode instead: a. Write out a GDB script: % echo thread apply backtrace all > backtrace.gdbscript % echo quit >> backtrace.gdbscript b. Find the process ID: % pgrep evolution 12345 c. Attach with the debugger in batch mode: % gdb -p 12345 --batch -x backtrace.gdbscript -p 12345 >backtrace.log 2>&1 d. Look at the backtrace.log file produced. If you decide to install the debuginfo packages, it might be worth following the rest of the steps above first you've got a basic backtrace, you can work out which packages you will need debuginfo for by looking at what functions are on the stack, e.g.: Thread 8 (Thread 1084229968 (LWP 25128)): #0 0x000000380b0c7956 in poll () from /lib64/libc.so.6 #1 0x00000035e9a23a94 in PR_Poll () from /usr/lib64/libnspr4.so #2 0x00002aaab5ee6118 in __cxa_pure_virtual () from /usr/lib64/firefox-2.0.0.4/components/libnecko.so #3 0x00002aaab5ee62f8 in __cxa_pure_virtual () from /usr/lib64/firefox-2.0.0.4/components/libnecko.so #4 0x00000035ea6775d7 in __cxa_pure_virtual () from /usr/lib64/firefox-2.0.0.4/libxpcom_core.so #5 0x00000035e9a2778d in __cxa_pure_virtual () from /usr/lib64/libnspr4.so #6 0x0000003e484061c5 in start_thread () from /lib64/libpthread.so.0 #7 0x000000380b0d062d in clone () from /lib64/libc.so.6 In the above example, I would expect to get a more useful backtrace after installing debuginfo packages for libnspr4, libxpcom_core and libnecko. Note that, in this case, libxpcom_core and libnecko are part of a packaged Firefox install and it's likely that there's a firefox-debuginfo package containing what I need for both of those libraries. While you're inside GDB, you can generate a dump of the process state (core dump) by using the command: (gdb) gcore /path/to/where/i/want/to/save/it/evo-core-hung This file can then be sent to the developers for further inspection. Don't send it to them unless they ask for it, because core files are typically quite large. It's also important to understand that the core file is very likely to contain sensitive private data (passwords, contents of emails), so it's worth trying to reproduce the problem with a fresh profile if you're intending to share a core file with the developers. The result of a system call trace generated with strace(1) is often useful for debugging. You can invoke strace like so: 1. Find the PID: % pgrep evolution 12345 2. Attach with strace: % strace -tt -f -p 12345 2>&1 | tee strace.log <lots of output> 3. Kill strace by entering Ctrl-C after letting it run for a little while. 4. Look at strace.log for a copy of the system call trace. Cheers, -mjg -- Matthew Gregan |/ /| [EMAIL PROTECTED]
