Using Valgrind and gdb in Scratchbox

(New page: Some hints for using valgrind tools in Scratchbox+Maemo These commands work in the 386 scratchbox target. First, standard way to use valgrind and gdb. af-sb-init.sh supports parameters fo...)
Line 1: Line 1:
-
Some hints for using valgrind tools in Scratchbox+Maemo
+
=Some hints for using valgrind tools in Scratchbox+Maemo=
These commands work in the 386 scratchbox target.
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:
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:
-
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 load of my_app. This way you can debug/valgrind the program you want.
Line 11: Line 11:
An interesting example would be: "I want to valgrind my status bar applet". And this is easy:
An interesting example would be: "I want to valgrind my status bar applet". And this is easy:
-
af-sb-init.sh start --valgrind=maemo_af_desktop
+
af-sb-init.sh start --valgrind=maemo_af_desktop
You'll get the results in /tmp/valgrind-maemo_af_desktop.log*
You'll get the results in /tmp/valgrind-maemo_af_desktop.log*
Line 19: Line 19:
For example, if you want to run massif of maemo_af_desktop, you would run:
For example, if you want to run massif of maemo_af_desktop, you would run:
-
export VALGRINDCMD=maemo_af_desktop
+
export VALGRINDCMD=maemo_af_desktop
-
export VALGRIND="valgrind <del>tool=massif </del>num-callers=50
+
export VALGRIND="valgrind <del>tool=massif </del>num-callers=50
-
      <del>trace-children=yes </del>depth=5 <del>format=html </del>log-file=/tmp/massif
+
        <del>trace-children=yes </del>depth=5 <del>format=html </del>log-file=/tmp/massif
-
      <del>alloc-fn=g_malloc </del>alloc-fn=g_malloc0 --alloc-fn=g_realloc
+
        <del>alloc-fn=g_malloc </del>alloc-fn=g_malloc0 --alloc-fn=g_realloc
-
      <del>alloc-fn=g_slice_alloc </del>alloc-fn=g_try_malloc
+
        <del>alloc-fn=g_slice_alloc </del>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
And you'll get your massif reports in /tmp (logs) and $PWD (html and postscripts).
And you'll get your massif reports in /tmp (logs) and $PWD (html and postscripts).
Line 33: Line 33:
If you want valgrind and gdb to find debug packages in Scratchbox, you need to do something like this:
If you want valgrind and gdb to find debug packages in Scratchbox, you need to do something like this:
-
#!/bin/sh
+
#!/bin/sh
-
# symlinks for debug symfiles in sbox
+
# symlinks for debug symfiles in sbox
-
mkdir -p /usr/lib/debug/targets
+
mkdir -p /usr/lib/debug/targets
-
cd /usr/lib/debug/targets
+
cd /usr/lib/debug/targets
-
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')
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).
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).
Line 43: Line 43:
When using Valgrind, you need to remember to use:
When using Valgrind, you need to remember to use:
-
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 Gnome Bugzilla for more information on Glib Gslice and Valgrind).
Line 49: Line 49:
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:
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:
-
#!/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 $*
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.
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.

Revision as of 17:04, 24 May 2008

Some hints for using valgrind tools in Scratchbox+Maemo

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:

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 load of my_app. This way you can debug/valgrind the program you want.

An interesting example would be: "I want to valgrind my status bar applet". And this is easy:

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

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.

For example, if you want to run massif of maemo_af_desktop, you would run:

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

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:

#!/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')

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:

export G_SLICE="always-malloc"

Otherwise Valgrind will report bogus leaks (see 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:

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

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.