16,602
edits
Changes
→Use profiling
An overview on how to debug GRAMPSGramps.
== 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 Gramps with the command:
python -m trace -t src/gramps.py
== Add debug statements ==
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 Gramps that will be printed out when GRAMPS Gramps runs without the optimize flag:
python gramps.py
== Use the log infrastructure ==
More info: [[Logging system]]
Short: in your code add data to the logger with: log.warning(), log.error(), log.info()...
Start GRAMPS Gramps with the --debug flag: python gramps.py --debug="name_of_the_logger"
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 ==
An example usage:
profile(self.save, *obj)
Then run GRAMPSGramps, 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.
That's it
See also [[GEPS_016:_Enhancing_GRAMPS_Processing_Speed]] for a sample of Profile Analysis.
== Use the winpdb python debugger ==
winpdb src/gramps.py
[[Image:Winpdb.png|thumb|Winpdb with GRAMPS Gramps loaded]] 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 introscpectionintrospection, 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 grampsGramps.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.
done.
(gdb)
</pre>
You just type now:
run grampsGramps.py
and then navigate gramps to the segmentation fault. After that, you see something like
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 [http://grapsus.net/blog/post/Low-level-Python-debugging-with-GDB] and [http://www.sourceware.org/gdb/onlinedocs/gdb.html].
[[Category:Developers/Reference]]
[[Category:Developers/Tutorials]]
[[Category:Developers/General]]
