10

Application Setup : I've C++11 application consuming the following 3rd party libraries :

  • boost 1.51.0
  • cppnetlib 0.9.4
  • jsoncpp 0.5.0

The application code relies on several in-house shared objects, all of them developed by my team (classical link time against those shared objects is carried out, no usage of dlopen etc.)

I'm using GCC 4.6.2 and the issue appears when using GDB 7.4 and 7.6.

OS - Red Hat Linux release 7.0 (Guinness) x86-64

The issue While hitting breakpoints within the shared objects code, and issuing gdb next command, sometimes GDB jumps backward to certain lines w/o any plausible reason (especially after exceptions are thrown, for those exceptions there suitable catch blocks)

Similar issues in the web are answered in something along the lines 'turn off any GCC optimization) but my GCC CL clearly doesn't use any optimization and asked to have debug information, pls note the -O0 & -g switches :

COLLECT_GCC_OPTIONS= '-D' '_DEBUG' '-O0' '-g' '-Wall' '-fmessage-length=0' '-v' '-fPIC' '-D' 'BOOST_ALL_DYN_LINK' '-D' 'BOOST_PARAMETER_MAX_ARITY=15' '-D' '_GLIBCXX_USE_NANOSLEEP' '-Wno-deprecated' '-std=c++0x' '-fvisibility=hidden' '-c' '-MMD' '-MP' '-MF' 'Debug_x64/AgentRegisterer.d' '-MT' 'Debug_x64/AgentRegisterer.d' '-MT' 'Debug_x64/AgentRegisterer.o' '-o' 'Debug_x64/AgentRegisterer.o' '-shared-libgcc' '-mtune=generic' '-march=x86-64'

Please also note as per Linux DSO best known methods, we have hidden visibility of symbols, only classes we would like to expose are being exposed (maybe this is related ???)

What should be the next steps in root causing this issue ?

Shmil The Cat
  • 4,548
  • 2
  • 28
  • 37
  • 1
    Your shared objects were probably compiled with optimisation enabled. – Paul R Jan 08 '14 at 10:04
  • 1
    @PaulR, please see my question, I clearly emphasized that no optimization switch is enabled, you got a snippet the shared object GCC command line within my question – Shmil The Cat Jan 08 '14 at 10:06
  • Yes, but are you sure you are compiling the in-house shared objects with the same compiler switches? I suspect they have their own makefile? – Paul R Jan 08 '14 at 10:07
  • Is it possible that the debugger's backward jumps are tracing the destruction of objects? – Mike Kinghan Jan 08 '14 at 10:08
  • @PaulR, I wrote the makefiles for those shared objects :), the snippet from above was taken from executing make on them – Shmil The Cat Jan 08 '14 at 10:09
  • OK - I would still double-check the build transcript though to make sure you didn't miss anything - I would want to see with my own eyes that `-O0` being passed to gcc for the relevant source files. – Paul R Jan 08 '14 at 10:11
  • @MikeKinghan, I don't think so, GDB jumps to lines where there objects which shouldn't be destroyed due to stack unwinding (they are out of the scope of the try block :( – Shmil The Cat Jan 08 '14 at 10:24
  • @PaulR - Thx for your support, my corporate prevents me from putting the build log on some hosting service so you can't see it by your own very eyes :) yet I've double checked it and -O0 is being propagated to each & every cpp file – Shmil The Cat Jan 08 '14 at 10:27
  • OK - I'll take your word for it. ;-) In that case I'm out of ideas. – Paul R Jan 08 '14 at 10:46

3 Answers3

7

This sort of problem is usually GIGO -- gdb is just acting in the way that the compiler has instructed it to act. So, it's typically a compiler bug rather than a gdb bug. I've seen this happen even with -O0 compilations. The example that comes to mind is that some versions of g++ emitted the location of a variable's declaration when emitting a call to the variable's destructor. This lead to this odd jumping behavior in otherwise straight-line code.

Tom Tromey
  • 21,507
  • 2
  • 45
  • 63
  • 1
    Yes, I have the same problem. I'm using C++11 (but I saw this with usual C++ and even plain C) and get strange backward jumps when -O0 is used. – likern Jul 21 '14 at 20:19
  • Likern, did you find a solution? I am trying to debug my program with double free and launched gdb, even after commenting out almost all the code, the debugger reached the last line: return 0 in main(), then jump back to earlier lines and caused a crash. If you run the program, it it fine. I am using Ubuntu, gcc 7.3.0-27. Not sure to upgrade gdb or gcc or both, I am using C++. – Kemin Zhou Dec 21 '18 at 23:39
0

I had a code producing wrong output, and when I tried to debug it with gdb, the lines were jumping arbitrarily. Finally I figured that it was not a gdb problem but a bug in g++: when -O3 was used the last line of a constructor was getting skipped. If I put a printf line after that line, the code would work fine! After changing CFLAGS from -O3 to -O0, the code gave the correct output. I was using c++11 with gcc-5.4.0

R71
  • 4,283
  • 7
  • 32
  • 60
  • In my case even using -g -O0 the gdb still jump back to previous lines even after finishing the program after the last line in main(). – Kemin Zhou Dec 22 '18 at 01:01
0

When I had a similar problem on the STM32L4R9I Evaluation board, I changed from compiling with -Os to -O0 and now it's working like a charm.

Be sure that you don't have any other file defining compilation flags.

Persike
  • 63
  • 5
  • This does not provide an answer to the question. Once you have sufficient [reputation](https://stackoverflow.com/help/whats-reputation) you will be able to [comment on any post](https://stackoverflow.com/help/privileges/comment); instead, [provide answers that don't require clarification from the asker](https://meta.stackexchange.com/questions/214173/why-do-i-need-50-reputation-to-comment-what-can-i-do-instead). - [From Review](/review/low-quality-posts/23909600) – L. F. Aug 28 '19 at 13:56
  • Hi L.F., Yes, you are right. My idea was just to advise him to re-check if the compilation flags were not being overwritten by something else. I would rather doing that commenting his topic, but I don't have reputation to that. Next time I will keep my thoughts to myself :) – Persike Aug 29 '19 at 06:53