Home/ Questions/Q 6974991
In Process

The Archive Base Latest Questions

Editorial Team
  • 0
Asked: 2026-05-27T17:18:35+00:00

I’m debugging some ANSI C code with gcc44 and gdb, on a 64bit Linux

  • 0

I’m debugging some ANSI C code with gcc44 and gdb, on a 64bit Linux CentOS 5.7 server.

Around the middle of one of my functions, I have a for loop that loops 192 times (there are 2 lines of code in the loop). If I setup gdb with a breakpoint at the start of the for loop, I can step through the for loop all 192 times and it exits the for loop and continues into the next line of code after the for loop. This is all stepping through the code in gdb using "s" or "n". Everything works fine.

Now, instead of stepping through the for loop using "s" or "n" to get to the next line of code after the for loop, I start gdb and then set a breakpoint at the line just after the end of the for loop. If I then press "c" in gdb, it gives me "Program exited normally". I expected gdb to stop at this breakpoint located on the line of code just after the for loop. (!?)

As another experiment, I learned that gdb DOES successfully stop on any breakpoint set on any line after the line of code immediately following the for loop.

Maybe others have had this experience judging by questions such as this (there are 2 additional references therein):

gdb error "Program exited normally"

It’s repeatable in gdb. Without digging into the code in question, anyone seen this behavior before and/or have any idea what I could check?

EDIT 1

If I include a printf("\n"); on the breakpoint line that gives problems above, moving what used to be on that line to one line below this printf code, then everything works fine (e.g. gdb stops on the printf line).

I can even set a breakpoint successfully on the previously-problematic line of code in question, which is now the next line after the printf line. Weird!

Share

Leave an answer

You must login to add an answer.

Need An Account,

1 Answer

  1. Editorial Team

    Your compiler is playing tricks on you.

    Well, not really, but it’s not doing exactly what you suspect.

    A first principals concept of the compiler would be to sequentially turn every line of C into one or more assembly instructions, and execute the assembly in the same order as the C code.

    In reality the compiler will reorganize things to optimize for speed or space. If an instruction is deemed to have no net effect on the program state it could be removed completely. Thus when you tell GDB to break on that line, well.. there is no assembly instruction with debugging information pointing to that line of C.

    • 0