Helmut Wollmersdorfer wrote: >Craig Ringer wrote: > > >>On Linux they have to get gdb (unless glibc detects the >>failure, eg a double free) but at least it's available and easy to give >>instructions for. >> >> > >Verbose please. Which commands (perl or console) can I use to get out >info from gdb? > >
If you want basic-user-oriented instructions for just getting a backtrace check out the GAIM "getting a backtrace" page: http://gaim.sourceforge.net/gdb.php . Detail: First, make sure the app is compiled with -g (debugging) or at the very least is not stripped (`file' on the executable/library can tell you that). A backtrace from a stripped binary is almost entirely useless. To debug, you'll usually want to launch the app under gdb: gdb --args /path/to/app [arg1 [ arg2 [arg3 [ ... ] ] ] You can alternately connect to a running process or debug a core file, as documented in the gdb man page. To get a crashing program to generate a core file you may need to change your ulimit (this setting affects the shell its run in and all child processes): ulimit -c unlimited Once gdb has started and shows the (gdb) prompt, if you ran the app from gdb type "run" and work as normal. If you connected to a running app, type "cont" and work as normal. A core file is "pre-crashed" and there's no point in running anything, so just skip to the next bit. When it crashes, the app will freeze instead of disappearing / reporting a crash. You can then look at the gdb console and see a brief crash report telling you what signal it crashed on and in what routine. [ after this applies to core files too: ] Type "bt" to get a full backtrace. You can also explore the state of the program when it was running - poke at local variables up the stack, at globals, and so on. gdb's built-in help is rather ... er ... brief, but is useful. There's more info out on the 'net. For more information, read the gdb man page. -- Craig Ringer
