Changes between Version 3 and Version 4 of GetABacktrace

Timestamp:

Sep 12, 2008, 7:58:57 PM (15 years ago)

Author:

elb

Comment:

--

GetABacktrace

@@ -13 +13 @@
 
 == The Easy Way ==
-If you can reproduce the crash, the easiest way to obtain a backtrace is by running with gdb.  Here are the basics:
+If you can reproduce the crash, the easiest way to obtain a backtrace is by running with gdb.  (Note that debugging finch requires a little more effort, [#GDBandfinch see below].)  Here are the basics:
 {{{
    ~ $ gdb pidgin
@@ -109 +109 @@
 There may be other useful information that can be retrieved from the core file, such as the values of variables. For this reason it's a good idea to keep the core file. If you upgrade Pidgin, the core file will no longer match the binary, and it won't be useful anymore; however, don't let that stop you from upgrading Pidgin, since there's a good chance your bug will have been fixed.
 
+== GDB and finch ==
+
+Because finch is a console-based application, running finch in gdb in a single terminal can lead to some quite bizarre effects.  Assuming that finch will at least start up without crashing, you can attach gdb to a running finch process from a second terminal in order to debug it as you would Pidgin.  Instead of following the instructions above ('{{{gdb finch}}}', then '{{{run}}}'), start finch as you normally would in a terminal.  Once it is up and running, open a second terminal and find its process ID using, e.g., the '{{{ps}}}' command.  Once you have its process ID, which we will call ''pid'', run '{{{gdb finch }}}''pid'' ' in the second terminal.  This should bring you to a {{{(gdb)}}} prompt, and the finch process will become unresponsive.  Similar to before, run:
+
+{{{
+   (gdb) handle SIGPIPE nostop
+   (gdb) continue
+}}}
+
+Note the use of {{{continue}}} rather than {{{run}}}.  From here on out, follow the directions above.
+
 == Additional Notes for Those Users Wanting To Do More ==
 Often, you will see a backtrace where one or more of the top lines is in `malloc()` or `g_malloc()`. When this happens, chances are your backtrace isn't very useful. The easiest way to find some useful information is to set the environment variable `MALLOC_CHECK_` to a value of 2. In bash this would be: