Using Valgrind and gdb in Scratchbox

(Re-write page for tone. Remove {{Template:Midgard article}} and Category:Midgard wiki)
Line 1: Line 1:
{{Midgard article}}
{{Midgard article}}
-
=Some hints for using valgrind tools in Scratchbox+Maemo=
+
= Hints for using valgrind tools in Maemo Scratchbox =
-
These commands work in the 386 scratchbox target.
+
-
First, standard way to use valgrind and gdb. af-sb-init.sh supports parameters for using these tools with a piece of software we want to study:
+
== Running Valgrind and gdb ==
 +
 
 +
The standard way to use Valgrind and gdb is the af-sb-init.sh script. af-sb-init.sh supports parameters for running the software we're interested in with tools:
  af-sb-init.sh start --valgrind=my_app
  af-sb-init.sh start --valgrind=my_app
  af-sb-init.sh start --gdb=my_app
  af-sb-init.sh start --gdb=my_app
-
Valgrind will store the results in /tmp/valgrind-my_app.log*. Gdb will show its prompt on load of my_app. This way you can debug/valgrind the program you want.
+
Valgrind will store the results in /tmp/valgrind-my_app.log*. gdb will show its prompt on loading my_app.
-
An interesting example would be: "I want to valgrind my status bar applet". And this is easy:
+
== Debugging applets ==
 +
 
 +
To debug a panel applet:
  af-sb-init.sh start --valgrind=maemo_af_desktop
  af-sb-init.sh start --valgrind=maemo_af_desktop
Line 17: Line 20:
You'll get the results in /tmp/valgrind-maemo_af_desktop.log*
You'll get the results in /tmp/valgrind-maemo_af_desktop.log*
-
If you want to run other valgrind tools, you would better use these environment variables: * VALGRINDCMD: the command you want to run inside valgrind. * VALGRIND: the valgrind command and parameters.
+
== Other Valgrind front ends ==
-
For example, if you want to run massif of maemo_af_desktop, you would run:
+
To use other Valgrind front-ends, set the following environment variables:
 +
* VALGRINDCMD: the command you want to run inside valgrind.
 +
* VALGRIND: the valgrind command and parameters, including the front-end to use.
 +
 
 +
For example, to run massif on maemo_af_desktop:
<pre>
<pre>
  export VALGRINDCMD=maemo_af_desktop
  export VALGRINDCMD=maemo_af_desktop
-
  export VALGRIND="valgrind <del>tool=massif </del>num-callers=50
+
  export VALGRIND="valgrind --tool=massif --num-callers=50
-
         <del>trace-children=yes </del>depth=5 <del>format=html </del>log-file=/tmp/massif
+
         --trace-children=yes --depth=5 --format=html -log-file=/tmp/massif
-
         <del>alloc-fn=g_malloc </del>alloc-fn=g_malloc0 --alloc-fn=g_realloc
+
         --alloc-fn=g_malloc --alloc-fn=g_malloc0 --alloc-fn=g_realloc
-
         <del>alloc-fn=g_slice_alloc </del>alloc-fn=g_try_malloc
+
         --alloc-fn=g_slice_alloc --alloc-fn=g_try_malloc
-
      - -alloc-fn=g_slice_alloc0"
+
        --alloc-fn=g_slice_alloc0"
  af-sb-init.sh start
  af-sb-init.sh start
  ... do your stuff ...
  ... do your stuff ...
  af-sb-init.sh stop
  af-sb-init.sh stop
</pre>
</pre>
-
And you'll get your massif reports in /tmp (logs) and $PWD (html and postscripts).
 
-
If you want valgrind and gdb to find debug packages in Scratchbox, you need to do something like this:
+
Your massif reports will be generated in /tmp (logs) and $PWD (html and postscripts).
 +
 
 +
== Debug packages ==
 +
 
 +
When gdb uses "realpath" on libraries in Scratchbox, the path returned starts with "/targets//", which causes some issues. You can see the effect of this if you run Valgrind or gdb through strace. This causes problems when using debug packages.
 +
 
 +
To use debug packages with Valgrind and gdb in Scratchbox, run this script:
<pre>
<pre>
  #!/bin/sh
  #!/bin/sh
Line 41: Line 53:
  ln -sf /usr/lib/debug $(sh -c '. /targets/links/scratchbox.config;echo $SBOX_TARGET_NAME')
  ln -sf /usr/lib/debug $(sh -c '. /targets/links/scratchbox.config;echo $SBOX_TARGET_NAME')
</pre>
</pre>
-
This is because when Gdb uses "realpath" on libraries in Sbox it gets a path starting with /targets//... You can see the effect of this if you "strace" Valgrind (or Gdb).
 
-
When using Valgrind, you need to remember to use:
+
== GSlice ==
 +
 
 +
When using Valgrind, set the environment variable G_SLICE:
  export G_SLICE="always-malloc"
  export G_SLICE="always-malloc"
-
Otherwise Valgrind will report bogus leaks (see Gnome Bugzilla for more information on Glib Gslice and Valgrind).
+
Otherwise Valgrind will report bogus leaks (see [http://bugzilla.gnome.org/show_bug.cgi?id=444444 this bug] in Gnome Bugzilla for more information on Glib Gslice and Valgrind).
-
Another thing to remember about Gdb is that the Maemo Sbox cross-gdb cannot debug ARM (EABI) core dumps. You need target Gdb for this. However, because Sbox will use the host (cross-gdb) binary if it exists, you need to tell Sbox to ignore that:
+
== Analysing ARM core dumps ==
 +
The cross-gdb used by default when it is installed in Scratchbox cannot debug ARM (EABI) core dumps. You need a natively compiled gdb to do this. To avoid using the cross-compiled gdb if it is installed, run your command with this script:
<pre>
<pre>
  #!/bin/sh
  #!/bin/sh
-
  # use native Gdb in Scratchbox
+
  # use native gdb in Scratchbox
  SBOX_REDIRECT_IGNORE=/usr/bin/gdb /usr/bin/gdb $*
  SBOX_REDIRECT_IGNORE=/usr/bin/gdb /usr/bin/gdb $*
</pre>
</pre>
-
You can check which Gdb is used with "gdb -v". If it says "--host=i686-pc-linux-gnu" on ARM target, it's a cross-gdb.
 
 +
To check which gdb you are running, run "gdb -v". If you see "--host=i686-pc-linux-gnu" when you are on ARM, then you are running cross-gdb.
[[Category:Development]]
[[Category:Development]]
-
[[Category:Midgard wiki]]
 
[[Category:Wiki page of the day]]
[[Category:Wiki page of the day]]

Revision as of 18:55, 14 July 2008

Image:Ambox_content.png
This is an article from the old midgard wiki that hasn't yet been fully updated for this wiki, please update it.
Please see the talk page for discussion.


Contents

Hints for using valgrind tools in Maemo Scratchbox

Running Valgrind and gdb

The standard way to use Valgrind and gdb is the af-sb-init.sh script. af-sb-init.sh supports parameters for running the software we're interested in with tools:

af-sb-init.sh start --valgrind=my_app
af-sb-init.sh start --gdb=my_app

Valgrind will store the results in /tmp/valgrind-my_app.log*. gdb will show its prompt on loading my_app.

Debugging applets

To debug a panel applet:

af-sb-init.sh start --valgrind=maemo_af_desktop

You'll get the results in /tmp/valgrind-maemo_af_desktop.log*

Other Valgrind front ends

To use other Valgrind front-ends, set the following environment variables:

  • VALGRINDCMD: the command you want to run inside valgrind.
  • VALGRIND: the valgrind command and parameters, including the front-end to use.

For example, to run massif on maemo_af_desktop:

 export VALGRINDCMD=maemo_af_desktop
 export VALGRIND="valgrind --tool=massif --num-callers=50
        --trace-children=yes --depth=5 --format=html -log-file=/tmp/massif
        --alloc-fn=g_malloc --alloc-fn=g_malloc0 --alloc-fn=g_realloc
        --alloc-fn=g_slice_alloc --alloc-fn=g_try_malloc
        --alloc-fn=g_slice_alloc0"
 af-sb-init.sh start
 ... do your stuff ...
 af-sb-init.sh stop

Your massif reports will be generated in /tmp (logs) and $PWD (html and postscripts).

Debug packages

When gdb uses "realpath" on libraries in Scratchbox, the path returned starts with "/targets//", which causes some issues. You can see the effect of this if you run Valgrind or gdb through strace. This causes problems when using debug packages.

To use debug packages with Valgrind and gdb in Scratchbox, run this script:

 #!/bin/sh
 # symlinks for debug symfiles in sbox
 mkdir -p /usr/lib/debug/targets
 cd /usr/lib/debug/targets
 ln -sf /usr/lib/debug $(sh -c '. /targets/links/scratchbox.config;echo $SBOX_TARGET_NAME')

GSlice

When using Valgrind, set the environment variable G_SLICE:

export G_SLICE="always-malloc"

Otherwise Valgrind will report bogus leaks (see this bug in Gnome Bugzilla for more information on Glib Gslice and Valgrind).

Analysing ARM core dumps

The cross-gdb used by default when it is installed in Scratchbox cannot debug ARM (EABI) core dumps. You need a natively compiled gdb to do this. To avoid using the cross-compiled gdb if it is installed, run your command with this script:

 #!/bin/sh
 # use native gdb in Scratchbox
 SBOX_REDIRECT_IGNORE=/usr/bin/gdb /usr/bin/gdb $*

To check which gdb you are running, run "gdb -v". If you see "--host=i686-pc-linux-gnu" when you are on ARM, then you are running cross-gdb.