[Scribus] Scribus Digest, Vol 37, Issue 62

[Craig Ringer]

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