When a hard crash occurs, you typically have no idea where the crash occurs. It is important to know the line where the crash occurs. So if you are able to reproduce the crash, restart GRAMPS with the command:

+

When a hard crash occurs, you typically have no idea where the crash occurs. It is important to know the line where the crash occurs. So if you are able to reproduce the crash, restart Gramps with the command:

python -m trace -t src/gramps.py

python -m trace -t src/gramps.py

+

+

This will usually generate vast terminal output and slow the system down for that, so redirecting output to a file is usually good:

+

+

python -m trace -t src/gramps.py >/tmp/trace.out

+

+

Then check the file "/tmp/trace.out" and save if needed, or redirect to somewhere else in the earlier step.

== Add debug statements ==

== Add debug statements ==

−

GRAMPS is run with the optimize flag.

+

Gramps is run with the optimize flag.

python -O gramps.py

python -O gramps.py

−

This gives you the option of adding debug statements. You can use the __debug__ variable or the assert statement for this. This allows us to add code to GRAMPS that will be printed out when GRAMPS runs without the optimize flag:

+

This gives you the option of adding debug statements. You can use the __debug__ variable or the assert statement for this. This allows us to add code to Gramps that will be printed out when Gramps runs without the optimize flag:

python gramps.py

python gramps.py

Line 21:

Line 24:

== Use the log infrastructure ==

== Use the log infrastructure ==

−

GRAMPS has built in the python log infratructure. GRAMPS runs with logging level logging.DEBUG to stderrh.

+

Gramps has built in the python log infratructure. Gramps runs with logging level logging.DEBUG to stderrh.

This is useful when working in different parts, adding info output, and selecting on the command line with --debug the logger you want to see output with.

== Use profiling ==

== Use profiling ==

−

GRAMPS has a convenience hook to allow you to do profiling. Profiling gives an overview how many times methods are called in a code fragment and how long each one took. It helps to find perfermance bottlenecks.

+

Gramps has a convenience hook to allow you to do profiling. Profiling gives an overview how many times methods are called in a code fragment and how long each one took. It helps to find performance bottlenecks.

An example usage:

An example usage:

Line 49:

Line 53:

profile(self.save, *obj)

profile(self.save, *obj)

−

Then run gramps, everytime you save, the profiler kicks in and prints to command line a report with the time for each function.

+

Then run Gramps, every time you save, the profiler kicks in and prints to command line a report with the time for each function.

So in short: replace the call to a function/method to calling profile with as first parameter the function/method, and other parameters the parameters of the function/method.

So in short: replace the call to a function/method to calling profile with as first parameter the function/method, and other parameters the parameters of the function/method.

That's it

That's it

+

+

See also [[GEPS_016:_Enhancing_GRAMPS_Processing_Speed]] for a sample of Profile Analysis.

+

+

== Use the winpdb python debugger ==

+

'''Note''': there are some issues with the winpdb debugger. For a workaround see bug ticket: {{bug|2564}}

Now, in File menu, select 'Open Source', and open the source file you want to debug. Now all debug options are possible. Eg, go to a line in the file with the cursor, and click the ''run to line'' button. The debugger will run to that point, and left show you all defined local variables with their value, as well as the stack frame.

+

+

Try it!

+

+

== Use gdb C debugger ==

+

+

With GObject introspection, much more can go wrong on a lower level, causing C errors. For these gdb can be used. You should install some debug libraries like libglib2.0-0-dbg, python-gobject-dbg, ... .

+

+

Then, you start in a terminal gdb in the directory where Gramps.py is stored with

+

+

gdb python

+

+

You should see something like:

+

+

<pre>

+

GNU gdb (Ubuntu/Linaro 7.2-1ubuntu11) 7.2

+

Copyright (C) 2010 Free Software Foundation, Inc.

+

License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>

+

This is free software: you are free to change and redistribute it.

+

There is NO WARRANTY, to the extent permitted by law. Type "show copying"

Contents

Hard crash

When a hard crash occurs, you typically have no idea where the crash occurs. It is important to know the line where the crash occurs. So if you are able to reproduce the crash, restart Gramps with the command:

python -m trace -t src/gramps.py

This will usually generate vast terminal output and slow the system down for that, so redirecting output to a file is usually good:

python -m trace -t src/gramps.py >/tmp/trace.out

Then check the file "/tmp/trace.out" and save if needed, or redirect to somewhere else in the earlier step.

Add debug statements

Gramps is run with the optimize flag.

python -O gramps.py

This gives you the option of adding debug statements. You can use the __debug__ variable or the assert statement for this. This allows us to add code to Gramps that will be printed out when Gramps runs without the optimize flag:

This is useful when working in different parts, adding info output, and selecting on the command line with --debug the logger you want to see output with.

Use profiling

Gramps has a convenience hook to allow you to do profiling. Profiling gives an overview how many times methods are called in a code fragment and how long each one took. It helps to find performance bottlenecks.

An example usage:

Add at the top of the file you want to use profiling:

from Utils import profile

Then, suppose you want to profile a save function on one of the editors. The save is called due to a connect done in the method _connect_signals. So, change the connect to save to a new method testsave you make:

Now, in File menu, select 'Open Source', and open the source file you want to debug. Now all debug options are possible. Eg, go to a line in the file with the cursor, and click the run to line button. The debugger will run to that point, and left show you all defined local variables with their value, as well as the stack frame.

Try it!

Use gdb C debugger

With GObject introspection, much more can go wrong on a lower level, causing C errors. For these gdb can be used. You should install some debug libraries like libglib2.0-0-dbg, python-gobject-dbg, ... .

Then, you start in a terminal gdb in the directory where Gramps.py is stored with

gdb python

You should see something like:

GNU gdb (Ubuntu/Linaro 7.2-1ubuntu11) 7.2
Copyright (C) 2010 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law. Type "show copying"
and "show warranty" for details.
This GDB was configured as "x86_64-linux-gnu".
For bug reporting instructions, please see:
<http://www.gnu.org/software/gdb/bugs/>...
Reading symbols from /usr/bin/python...Reading symbols from /usr/lib/debug/usr/bin/python2.7...done.
done.
(gdb)

You just type now:

run Gramps.py

and then navigate gramps to the segmentation fault. After that, you see something like

Program received signal SIGSEGV, Segmentation fault.
0x00007ffff5e7226b in g_type_check_value () from /usr/lib/x86_64-linux-gnu/libgobject-2.0.so.0
(gdb)

Now you request the backtrace, to see the code that leads to the error:

(gdb) bt

which will print the backtrace. You are now ready to use your C knowledge to fix the bug!

Trace GObject/GTK warnings

GTK has several possible warning levels, which might pop up on the terminal, without visible problems in Gramps. To trace these, do the following in the :

gdb python

and at the gdb prompt indicate to stop on log output:

b g_log if log level < 32
r Gramps.py

Now Gramps will stop on serious messages, and you can use

bt

to get a backtrace of the C stack showing where the message originated and what called the function, etc.

Learn More

To learn more about debugging python and C debugging with gdb, see [2] and [3].