Debugging a SIGSEGV Backtrace Part 2

Today I found an effortless way to debug a sisseg backtrace using gdb:

The problem was this backtrace:
[17450 XX 23:31:34 (+18)][10237] <TWS_ERROR> {sigsafe} src/common.c@1303: [bt]: (5) /usr/lib64/twsch/[0x7f64a2467669]

The procedure:

1 – First of all we need to open a instance of the process with gdb, and run only to the begin of the main function to let the process dynamic load the libraries:

$ gdb ./your_buggy_app

(gdb) b main

2 – use the function name and the offset in this way

(gdb) info line *ott_thread+0x1fd

the result:

Line 426 of “src//ch.c” starts at address 0x7fffee99a65d <ott_thread+497> and ends at 0x7fffee99a68b <ch_thread+543>.

More clear? Throw it some water



Debugging a SIGSEGV Backtrace

Before begin my post I need introduce you the term of backtrace, a backtrace is a series of the last function calls in your program (view $man backtrace), with a backtrace you can access the call stack, so, in other words how did you get to that point in your program.

Today working on a code I got a SIGSEGV and the obviously subsecuently crash. After checking the log I found this backlog (which was made using backtrace()):

[17101 XX 12:17:05 (+6)][23417] {sigsafe} src/common.c@1233: SIGSEGV(11), puntero 0xc0 desde 0x7f288f7c79aa
[17101 XX 12:17:05 (+6)][23417] {sigsafe} src/common.c@1252: [bt]: (0) /usr/lib64/twsmedia/[0x7f288f7c79aa]
[17101 XX 12:17:05 (+6)][23417] {sigsafe} src/common.c@1252: [bt]: (1) /usr/lib64/twsmedia/[0x7f288f7c79aa]
[17101 XX 12:17:05 (+6)][23417] {sigsafe} src/common.c@1252: [bt]: (2) /usr/sbin/mwconstructor[0x40a2c0]
[17101 XX 12:17:05 (+6)][23417] {sigsafe} src/common.c@1252: [bt]: (3) /lib64/[0x7f289173edf5]
[17101 XX 12:17:05 (+6)][23417] {sigsafe} src/common.c@1252: [bt]: (4) /lib64/[0x7f288834c1ad]

Viewing this log you know where the problem was … but… Which line is it?

The simplest way to debug(if you dont know this trick) is run gdb and try to reproduce the bug, but not every time its a great decision.

But, wait! what you want to do then?

We will search directly inside the .o of the library for the problematic line… Lets begin:

Use nm to find the function’s start position on .o file

nm src/twsmedia_widget.o | less

You will find something like this line

000000000000cc9a T twsmedia_widget_alarm_pool_draw

0xcc9a is the start line of twsmedia_widget_alarm_pool_draw function

Then, add 0x1680 offset (twsmedia_widget_alarm_pool_draw+0x1680)) to that pos, in this case resulting in 0xe31a

For last, call addr2line, to search for the specific line in the .text section of the object

$ addr2line -j .text -e src/twsmedia_widget.o 0x000000000000e31a

And Problem solved! Now we have the problematic line:  src/twsmedia_widget.c:3139

Its important to highlight that this method won’t work in some scenarios like having static functions (because you won’t have the function names in the backtrace).

That’s all for now, see you later!


tag tag tag!

The problem

Lot of branches, therefore much disorder. To solve this we can tag and archive.

To keep the git repo tidy we usually recommend to avoid leaving open branches that have already been merged to the main branch.

How to tag a branch and then close correctly on local and remote repos..

1 - Create the tag (locally)
     git tag archive/<branchname> <branchname>
2 - push the new tag to remote
     git push --tags
3 - delete branch locally
     git branch -d <branchname>
4 - delete branch on remote repo
     git push origin --delete <branch_name>
5 - go to master branch (or other branch)
     git checkout master

How to recover older tagged branch

1 - go to tag
     git checkout archive/<branchname>
2 - recreate branch
     git checkout -b new_branch_name

This is all for now! matta ne!