1

I am trying to figure out why gdb is not behaving as expected. Not sure what triggered this. After seeing this problem, I wrote a minimal version of the main function. It finished the last line and exited properly. After adding one more function, the jumping came back. Even after commenting out the added line the jumping back does not go away.

I am not sure this is related the the linking to my own library even after commenting out most of the code (not a single line reference my own library), the build process still use the linking (automake):

LDADD = ../libmyown.la

This line was used to add libs to to many other programs built in this directory. I tested different versions of gdb and gcc, with the latest being 8.2 for both programs. Have used the -g -O0, -ggdb -O0 option. I have seen postings in Stackoverflow about this type of behavior. Not sure I am hitting this behavior or it was some bug in my own library whose linking caused this jumping back behavior. Although this posting appears to be redundant, but I am trying to provide more context information. Hopefully some else of myself will find a solution and help others.

Except for the jumping problem in gdb, the binary program execute properly.

Here is a slightly expanded version of the main demonstrating the jumping issue:

Breakpoint 1, main (argc=1, argv=0x7fffffffdeb8) at alnlocalmany.cpp:66
66     if (isDNA(reffile)) {
(gdb) n
67        alignDNAMany(reffile, dbfile, outfile);
(gdb) 
68        return 0;
(gdb) s
39     string reffile, dbfile, outfile;
(gdb) s
73  }
(gdb) s
0x00007ffff6d97b97 in __libc_start_main () from /lib/x86_64-linux-gnu/libc.so.6
(gdb) s
Single stepping until exit from function __libc_start_main,
which has no line number information.
[Inferior 1 (process 15621) exited normally]

Note it jump from 68 to 39 (first line in main) then 73 (ending curly bracket of main)

ldav1s
  • 15,885
  • 2
  • 53
  • 56
Kemin Zhou
  • 6,264
  • 2
  • 48
  • 56
  • 1
    Just a guess - it's probably running the destructor of `string`, so it goes back to where it was declared because there's no other code it can show. Have you tried stepping in instead of stepping over to see what happens? – user1118321 Dec 24 '18 at 05:05
  • Using next (n) got the same result as (s). Even when I construct a main with only a few lines of code, without using any non-std library, I still saw this behavior. Otherwise, the binary (full program is much more) is perfect. I experimented (my Ph.D. was experimental science) for two days and did not discover anything interesting. I will take a break for now. – Kemin Zhou Dec 24 '18 at 06:46
  • What if you remove all `std::string` type variables and other variables with destructors? So far this looks like a duplicate of https://stackoverflow.com/q/20992356/72178. – ks1322 Dec 25 '18 at 18:12
  • Even with the string declaration, in my main, if there was no other function declarations in the source file, gdb will finish at the last return line without jumping to previous line. Sounds like destructor calling. When the function becomes complicated, it does go backward from higher line number so to smaller line number (destructor calling order). I think destructor explains the behavior. – Kemin Zhou Dec 25 '18 at 18:30
  • It is code from that line that is actually executing. You can think of `Foo x;` as a constructor that executes immediately and a destructor that executes at the end of the scope. – David Schwartz Jan 05 '19 at 00:28

1 Answers1

2

There was a similar gcc bug 49951 in the past which was later closed with the status RESOLVED FIXED. However it can be reproduced as of now with the current version of gcc (I tested with gcc 8.2.1). Other people also claim that the bug was not fixed, see https://gcc.gnu.org/bugzilla/show_bug.cgi?id=49951#c20.

As a workaround you can try to use clang instead of gcc, at least the bug was not reproduced on test example from gcc bug 49951 when building with clang. You can also downgrade gcc to version 4.4 but it is too old for now.

ks1322
  • 33,961
  • 14
  • 109
  • 164