Debugging Scilab 5

Easy way with GNU/Linux / Unix

As the syntax for debugging Scilab with libtool is not obvious, two options have been added for running a debug session in either gdb or KDbg.


$ $SCI/bin/scilab -debug

Will run Scilab in debug mode under gdb.

To launch Scilab itself with options, in gdb, run :

(gdb) run  -ns  -nwni -f modules/functions/scripts/buildmacros/buildmacros.sce


$ $SCI/bin/scilab -debug-kdbg

Will run Scilab in debug mode under KDbg, a front-end for gdb.

To launch Scilab itself with options and/or set up environment variables, choose Execution|Arguments and specify your options in the Program Arguments dialog before you run the program using Execution|Run.

More information: KDbg User's Manual (English)

Hard way with GNU/Linux / Unix

As Scilab is using libtool, in the development environment, instead of creating a binary into the source root directory (actually the binary is store here : .libs/lt-scilab-bin), it creates a script which will setup the LD_LIBRARY_PATH for each library. Consequently, ddd/gdb/kdbg will not work (they expect a binary, not a script). Fortunately, libtool provides a mechanism for this :

$ ./libtool --mode=execute gdb scilab-bin

gdb will now work as expected ! Of course, you can change gdb for any more user-friendly program. Actually, KDbg is started this way.

For example :

~/dev/scilab5$  ./libtool --mode=execute gdb scilab-bin
GNU gdb 6.5-debian
Copyright (C) 2006 Free Software Foundation, Inc.
GDB is free software, covered by the GNU General Public License, and you are
welcome to change it and/or distribute copies of it under certain conditions.
Type "show copying" to see the conditions.
There is absolutely no warranty for GDB.  Type "show warranty" for details.
This GDB was configured as "i486-linux-gnu"...Using host libthread_db library "/lib/tls/".
(gdb) run  -ns  -nwni -f modules/functions/scripts/buildmacros/buildmacros.sce
Starting program: /home/sylvestre/dev/scilab5/.libs/lt-scilab-bin -ns  -nwni -f modules/functions/scripts/buildmacros/buildmacros.sce

With scilab 5, because it uses java and because java doesn't seems to support well gdb, you must use a work around to perform a debugging of a scilab script:

First launch scilab without the -debug flag. This steps will allow scilab to launch java and other things without problems. Once scilab is launched, you have to "catch" scilab using gdb:

gdb --pid=`pidof scilab-bin`
./libtool --mode=execute gdb -p `pidof scilab-bin`

Now scilab is frozen and gdb waits for a new command to be entered. Inside gdb, just type:


To allow scilab to continue its normal behavior

Debugging Scilab through a core dump

In some special condition, it is interesting of not launching Scilab into the debugger (for example, Slave instances in MPI or PVM). Then, using the core dump to see the state of the memory before the crash will be an good solution.

To generate a core dump :

$ ulimit -c 654646466

Launch Scilab and get the crash

The command will be :

$ ./libtool --mode=execute gdb ./scilab-bin

gdb will load all the env before the crash.

Debugging in STD or NW mode

When Scilab is called in STD or NW mode, the JVM is load. This process is triggering some segmentation faults which are not related to Scilab. It is possible to continue without any impact (press c for that). in gdb, it is also possible to disable the stop on the seg fault:

handle SIGSEGV nostop print

Microsoft Windows with Visual Studio (C)

Build Scilab with configuration "debug" . press F5 in Visual Studio to start debugging. More informations about how to debug a program with Visual Studio 2005

Debugging symbols and optimization options

Too much optimization can sometimes lead to debuggers complaining about unreachable symbols. Default behavior for optimization is -O2 (whether debug or release version is being compiled). Explicitly specifying that no optimization is wanted is therefore necessary to obtain full access to all debugging symbols. Under Linux, the following syntax can be used to override default flags:

$ ./configure CFLAGS="-g -O0" FFLAGS="-g -O0" CXXFLAGS="-g -O0"

Of course, a full recompilation is needed after this kind of instruction.

Profiling Scilab 5

Memory leaks

In order to avoid memory leak, it can be interesting to launch Scilab into a profiling environment. The command is :

$ SCI/bin/scilab -profiling

This command will launch Scilab into Valgrind and display all memory errors found. By default, many warnings coming from JVM, TCL/TK, libc, etc are trapped by Valgrind (see tools/profiling/valgrind.supp from the list). If you want to add more ignores into that list, Valgrind is automatically generating the appropriate syntax when an error is found. Just copy and paste the block { } and put it in tools/profiling/valgrind.supp

Please note that on x86_64, the profiling can fail on GUI mode due to a valgrind bug.

Call graph

To check which functions is called and how many times, we have an option in the Scilab startup script :

$ SCI/bin/scilab-cli -profiling-visu  -e "disp(%pi);exit"

This command will launch Scilab with his option (display Pi here) and generates a file called <callgrind.out.PID>, this file is not intended for human but for software like kcachegrind

kcachegrind callgrind.out.<pid>

will display a lot of nice graphics !

If you want the libc6 symbols to be displayed, install the package libc6-dbg (name under Debian & Ubuntu) and add /usr/lib/debug to the LD_LIBRARY_PATH before loading kcachegrind

More information

More information about profiling (French)

public: Debugging and Profiling Scilab 5 (last edited 2013-02-26 10:29:18 by Sylvestre Ledru)