1

我目前正在处理 Qt/zlib 中的一个错误，我正在尝试检查一个变量是否在它崩溃的行之前已经损坏，所以我习惯于break 1245在前一行设置中断，然而：

(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);

这是 SEGFAULTing 所在的行，而不是我设置的断点。gdb 中的错误或一些古怪的行为？

编辑：添加我正在处理的区域列表：

(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)

编辑：从评论中获取建议并使用来自 ubuntu（apt-get 源）的源包重新构建它，并使用 CFLAGS 和 SFLAGS 强制为 -O0 进行构建，但是它现在不会在 gdb 中为段错误返回任何行号，所以我认为我在某个地方出错了。

4

1 回答 1

3

这是 SEGFAULTing 所在的行，而不是我设置的断点

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.

于 2012-04-25T17:36:26.870 回答