[Scribus] Scribus Digest, Vol 37, Issue 62
Sat Mar 25 12:34:45 CET 2006
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
>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:
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
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.
More information about the scribus