Difference between revisions of "Debug"

From VideoLAN Wiki
Jump to navigation Jump to search
 
(3 intermediate revisions by the same user not shown)
Line 24: Line 24:
  
 
This depends heavily on which debugger you use, and which platform you run.
 
This depends heavily on which debugger you use, and which platform you run.
The most common choice is the GNU debugger, a.k.a. <code>gdb</code>
+
The most common choice is the GNU debugger, a.k.a. <code>gdb</code>:
  
{{{
+
<pre>
 
# gdb --args ./vlc -Irc -vv
 
# gdb --args ./vlc -Irc -vv
 
...
 
...
Line 32: Line 32:
 
...
 
...
 
(gdb) thread apply all bt
 
(gdb) thread apply all bt
}}}
+
</pre>
 +
 
 +
There is also a dedicated [[Tutorial for gdb debug under Win32|tutorial for GDB on Windows]].
  
 
=== What does it look like? ===
 
=== What does it look like? ===
  
 
This is a debug-friendly back-trace:
 
This is a debug-friendly back-trace:
''Program received signal SIGSEGV, Segmentation fault.''
+
<pre>
''[Switching to Thread 0xb22e9b90 (LWP 17982)]''
+
Program received signal SIGSEGV, Segmentation fault.
''0xb7a965e8 in CDDAFormatTitle (p_access=0x842afe0, i_track=99 'c') at info.c:630''
+
[Switching to Thread 0xb22e9b90 (LWP 17982)]
''630    info.c: No such file or directory.''
+
0xb7a965e8 in CDDAFormatTitle (p_access=0x842afe0, i_track=99 'c') at info.c:630
''        in info.c''
+
630    info.c: No such file or directory.
''(gdb) bt full''
+
        in info.c
 +
(gdb) bt full
 
  #0  0xb7a965e8 in CDDAFormatTitle (p_access=0x842afe0, i_track=99 'c') at
 
  #0  0xb7a965e8 in CDDAFormatTitle (p_access=0x842afe0, i_track=99 'c') at
 
  info.c:630
 
  info.c:630
Line 73: Line 76:
 
  #10 0xb7ddb09e in clone () from /lib/libc.so.6
 
  #10 0xb7ddb09e in clone () from /lib/libc.so.6
 
  No symbol table info available.
 
  No symbol table info available.
 +
</pre>
  
 
And that is a not debug-friendly back-trace, which is indeed useless for developers:
 
And that is a not debug-friendly back-trace, which is indeed useless for developers:
''Program received signal SIGSEGV, Segmentation fault.''
+
<pre>
''[Switching to Thread -1342661712 (LWP 8792)]''
+
Program received signal SIGSEGV, Segmentation fault.
''0xb7db65ab in __module_Need () from /usr/lib/libvlc.so.0''
+
[Switching to Thread -1342661712 (LWP 8792)]
''(gdb) bt''
+
0xb7db65ab in __module_Need () from /usr/lib/libvlc.so.0
 +
(gdb) bt
 
  #0  0xb7db65ab in __module_Need () from /usr/lib/libvlc.so.0
 
  #0  0xb7db65ab in __module_Need () from /usr/lib/libvlc.so.0
 
  #1  0xb7ec5c34 in ?? () from /usr/lib/libvlc.so.0
 
  #1  0xb7ec5c34 in ?? () from /usr/lib/libvlc.so.0
Line 92: Line 97:
 
  #10 0x00000003 in ?? ()
 
  #10 0x00000003 in ?? ()
 
  #11 0x00000000 in ?? ()
 
  #11 0x00000000 in ?? ()
 +
</pre>
  
 
=== Is a backtrace enough to debug? ===
 
=== Is a backtrace enough to debug? ===

Latest revision as of 10:04, 17 December 2020

While compiling VLC media player, you can make a debug build using --enable-debug on the ./configure script command line.

Those debug factoids are common to every programs, not just VLC.

What it is used for

Of course, binaries compiled in debug mode will or should more-or-less behave like the release ones. Differences include:

  • Invalid internal states may cause assertion failure and crash the program with an explicit error, while the program would continue running in release version (and possibly crash later in weirder manner).
  • Binary back-traces are meaningful and usually more legible in this mode since symbols are embedded in the binaries.

As such, the main purpose is for developers to make debug-friendly binaries and investigate crashes and other bugs.

How to enable it

As noted above, you basically just have to add CFLAGS="-g" CXXFLAGS="-g" --enable-debug parameters at the ./configure stage.

For stepping into code, better is to do CFLAGS="-g -Og" CXXFLAGS="-g -Og" also add --disable-optimizations. For more information see VLC configure help.

Back-traces

A back-trace is a snapshot of the process call-flow at a given time during execution.

How to make a back-trace

This depends heavily on which debugger you use, and which platform you run. The most common choice is the GNU debugger, a.k.a. gdb:

# gdb --args ./vlc -Irc -vv
...
(gdb) run
...
(gdb) thread apply all bt

There is also a dedicated tutorial for GDB on Windows.

What does it look like?

This is a debug-friendly back-trace:

Program received signal SIGSEGV, Segmentation fault.
[Switching to Thread 0xb22e9b90 (LWP 17982)]
0xb7a965e8 in CDDAFormatTitle (p_access=0x842afe0, i_track=99 'c') at info.c:630
630     info.c: No such file or directory.
        in info.c
(gdb) bt full
 #0  0xb7a965e8 in CDDAFormatTitle (p_access=0x842afe0, i_track=99 'c') at
 info.c:630
         psz_name = <value optimized out>
         config_varname = <value optimized out>
         p_cdda = <value optimized out>
         psz_mrl = 0x8277238 "cddax:///dev/sr0@T99"
 #1  0xb7a94b0f in CDDAReadBlocks (p_access=0x842afe0) at access.c:264
         psz_title = <value optimized out>
         go_on = <value optimized out>
         p_block = <value optimized out>
         p_cdda = (cdda_data_t *) 0x84323c0
         i_blocks = 20
         __func__ = "CDDAReadBlocks"
 [...]
 #6  0xb6acfe9c in Demux (p_demux=0x833dcb0) at ../../include/vlc_stream.h:189
         p_sys = (demux_sys_t *) 0x842eca8
         i_pos = <value optimized out>
         p_block = (block_t *) 0x859f380
 #7  0xb7f34bae in MainLoop (p_input=0x8429c08) at input/input.c:538
         b_force_update = 0
         i_ret = <value optimized out>
         i_type = 138588128
         val = {i_int = 1064861644, b_b..........= 0 '\0', h = 0 '\0'}}
         i_intf_update = 1214500117823853
 #8  0xb7f362b2 in Run (p_input=0x8429c08) at input/input.c:444
 No locals.
 #9  0xb7e7917b in start_thread () from /lib/libpthread.so.0
 No symbol table info available.
 #10 0xb7ddb09e in clone () from /lib/libc.so.6
 No symbol table info available.

And that is a not debug-friendly back-trace, which is indeed useless for developers:

Program received signal SIGSEGV, Segmentation fault.
[Switching to Thread -1342661712 (LWP 8792)]
0xb7db65ab in __module_Need () from /usr/lib/libvlc.so.0
(gdb) bt
 #0  0xb7db65ab in __module_Need () from /usr/lib/libvlc.so.0
 #1  0xb7ec5c34 in ?? () from /usr/lib/libvlc.so.0
 #2  0xb5487553 in ?? ()
    from /usr/lib/vlc/stream_out/libstream_out_transcode_plugin.so
 #3  0x00000009 in ?? ()
 #4  0xb7ec3c74 in ?? () from /usr/lib/libvlc.so.0
 #5  0x0854bef8 in ?? ()
 #6  0x08525a00 in ?? ()
 #7  0xb7efaf04 in ?? () from /usr/lib/libvlc.so.0
 #8  0xb7dce493 in __vlc_object_release () from /usr/lib/libvlc.so.0
 #9  0x0000006f in ?? ()
 #10 0x00000003 in ?? ()
 #11 0x00000000 in ?? ()

Is a backtrace enough to debug?

It is not enough for someone else than you to fix a bug. At least, you really should describe what you were doing, how to reproduce the bug if you can, etc.

If you try to fix a bug with someone else or if you are asking help on your backtrace, better is really to use an up-to-date VLC source-code. Otherwise, say so and maybe give the commit ID/VLC tag you are working on.

See also