Reputation: 11754
I'm working through a bug in Qt/zlib at the moment, and I'm trying to check whether a variable has become corrupt prior to the line it's crashing on, so I've used break 1245
to set the break on the previous line, however:
(gdb) info break
Num Type Disp Enb Address What
6 breakpoint keep y 0x02cb0e1e in inflateEnd at inflate.c:1245
breakpoint already hit 6 times
(gdb) c
Continuing.
[Thread 0xb103db70 (LWP 26146) exited]
[Thread 0xb5a74b70 (LWP 26143) exited]
Breakpoint 6, inflateEnd (strm=0x86ccdc0) at inflate.c:1246
1246 if (state->window != Z_NULL) ZFREE(strm, state->window);
Which is the line that it's SEGFAULTing on rather than the breakpoint I've set. Bug in gdb or some quirky behaviour?
EDIT: Adding the list of the area I'm working on:
(gdb) list
1241 {
1242 struct inflate_state FAR *state;
1243 if (strm == Z_NULL || strm->state == Z_NULL || strm->zfree == (free_func)0)
1244 return Z_STREAM_ERROR;
1245 state = (struct inflate_state FAR *)strm->state;
1246 if (state->window != Z_NULL) ZFREE(strm, state->window);
1247 ZFREE(strm, strm->state);
1248 strm->state = Z_NULL;
1249 Tracev((stderr, "inflate: end\n"));
1250 return Z_OK;
(gdb)
EDIT: Took the advice from the comments and rebuilt it using the source packages from ubuntu (apt-get source) and building with CFLAGS and SFLAGS forced to -O0, however it now doesn't return any line numbers within gdb for the segfault, so I think I've gone wrong somewhere.
Upvotes: 2
Views: 3279
Reputation: 213877
Which is the line that it's SEGFAULTing on rather than the breakpoint I've set
This is expected when debugging optimized code (which inflate.c
likely is). The compiler moves instructions around, making code execution "jump around" when you step through it.
Upvotes: 4