glibc backtrace() gives line no off by one - Linux

This is a discussion on glibc backtrace() gives line no off by one - Linux ; The backtrace() provides complete stacktrace. Using backtrace_symbols(), stacktrace can be printed as: ../build/gtest(func1_name+0x129) [0x80484bd] ../build/gtest(func2_name+0x193) [0x8048527] /lib/libc.so.6(__libc_start_main+0xbd) [0x400483c1] here, the first part:name of the binary func1_name: mangelled func name in case of C++ 0x129: is the offset in the function ...

+ Reply to Thread
Results 1 to 4 of 4

Thread: glibc backtrace() gives line no off by one

  1. glibc backtrace() gives line no off by one

    The backtrace() provides complete stacktrace. Using
    backtrace_symbols(), stacktrace can be printed as:

    ../build/gtest(func1_name+0x129) [0x80484bd]
    ../build/gtest(func2_name+0x193) [0x8048527]
    /lib/libc.so.6(__libc_start_main+0xbd) [0x400483c1]

    here,
    the first part:name of the binary
    func1_name: mangelled func name in case of C++
    0x129: is the offset in the function
    0x80484bd: Actual address

    if 0x80484bd is passed to addr2line, it returns filename:line no.

    However, line no. is always the next line from the call.

    so, if

    23 foo()
    24
    25 int i=0;

    if i am expecting line no. of foo(), it returns line on if int i=0;

    interestingly, gdb also provides same actual address. Therefore, it
    seems like gdb is doing something more to get correct line no.

    Let me know if you have any ideas about how to get correct line no.
    from backtrace() and addr2line.

    Thanks,
    Vinayak


  2. Re: glibc backtrace() gives line no off by one

    vinayak.datar@gmail.com writes:

    > The backtrace() provides complete stacktrace. Using
    > backtrace_symbols(), stacktrace can be printed as:
    >
    > ./build/gtest(func1_name+0x129) [0x80484bd]
    > ./build/gtest(func2_name+0x193) [0x8048527]
    > /lib/libc.so.6(__libc_start_main+0xbd) [0x400483c1]
    >
    > here,
    > the first part:name of the binary
    > func1_name: mangelled func name in case of C++
    > 0x129: is the offset in the function
    > 0x80484bd: Actual address
    >
    > if 0x80484bd is passed to addr2line, it returns filename:line no.
    >
    > However, line no. is always the next line from the call.
    >
    > so, if
    >
    > 23 foo()
    > 24
    > 25 int i=0;
    >
    > if i am expecting line no. of foo(), it returns line on if int i=0;
    >
    > interestingly, gdb also provides same actual address. Therefore, it
    > seems like gdb is doing something more to get correct line no.
    >
    > Let me know if you have any ideas about how to get correct line no.
    > from backtrace() and addr2line.


    I'm guessing backtrace() gives you the return address of each frame.
    This would normally be on the line after the function call.

    --
    Måns Rullgård
    mans@mansr.com

  3. Re: glibc backtrace() gives line no off by one

    On Apr 1, 3:09 pm, Måns Rullgård wrote:
    > vinayak.da...@gmail.com writes:
    > > Thebacktrace() provides complete stacktrace. Using
    > > backtrace_symbols(), stacktrace can be printed as:

    >
    > > ./build/gtest(func1_name+0x129) [0x80484bd]
    > > ./build/gtest(func2_name+0x193) [0x8048527]
    > > /lib/libc.so.6(__libc_start_main+0xbd) [0x400483c1]

    >
    > > here,
    > > the first part:name of the binary
    > > func1_name: mangelled func name in case of C++
    > > 0x129: is the offset in the function
    > > 0x80484bd: Actual address

    >
    > > if 0x80484bd is passed to addr2line, it returns filename:line no.

    >
    > > However, line no. is always the next line from the call.

    >
    > > so, if

    >
    > > 23 foo()
    > > 24
    > > 25 int i=0;

    >
    > > if i am expecting line no. of foo(), it returns line on if int i=0;

    >
    > > interestingly, gdb also provides same actual address. Therefore, it
    > > seems like gdb is doing something more to get correct line no.

    >
    > > Let me know if you have any ideas about how to get correct line no.
    > > frombacktrace() and addr2line.

    >
    > I'm guessingbacktrace() gives you the return address of each frame.
    > This would normally be on the line after the function call.
    >
    > --
    > Måns Rullgård
    > m...@mansr.com- Hide quoted text -
    >
    > - Show quoted text -


    Yes. I guess that's the reason.

    However, gdb does show correct line no. If I need to show correct line
    no, what should I do?


  4. Re: glibc backtrace() gives line no off by one

    vinayak.datar@gmail.com writes:

    > On Apr 1, 3:09 pm, Måns Rullgård wrote:
    >> vinayak.da...@gmail.com writes:
    >> > Thebacktrace() provides complete stacktrace. Using
    >> > backtrace_symbols(), stacktrace can be printed as:

    >>
    >> > ./build/gtest(func1_name+0x129) [0x80484bd]
    >> > ./build/gtest(func2_name+0x193) [0x8048527]
    >> > /lib/libc.so.6(__libc_start_main+0xbd) [0x400483c1]

    >>
    >> > here,
    >> > the first part:name of the binary
    >> > func1_name: mangelled func name in case of C++
    >> > 0x129: is the offset in the function
    >> > 0x80484bd: Actual address

    >>
    >> > if 0x80484bd is passed to addr2line, it returns filename:line no.

    >>
    >> > However, line no. is always the next line from the call.

    >>
    >> > so, if

    >>
    >> > 23 foo()
    >> > 24
    >> > 25 int i=0;

    >>
    >> > if i am expecting line no. of foo(), it returns line on if int i=0;

    >>
    >> > interestingly, gdb also provides same actual address. Therefore, it
    >> > seems like gdb is doing something more to get correct line no.

    >>
    >> > Let me know if you have any ideas about how to get correct line no.
    >> > frombacktrace() and addr2line.

    >>
    >> I'm guessingbacktrace() gives you the return address of each frame.
    >> This would normally be on the line after the function call.

    >
    > Yes. I guess that's the reason.
    >
    > However, gdb does show correct line no. If I need to show correct line
    > no, what should I do?


    Do whatever gdb does or use gdb directly.

    --
    Måns Rullgård
    mans@mansr.com

+ Reply to Thread