开发者

Why are some statements skipped in gdb?

开发者 https://www.devze.com 2023-03-10 13:59 出处:网络
I\'m debugging this code : len = NGX_SYS_NERR * sizeof(ngx_str_t); ngx_sys_errlist = malloc(len); if (ngx_sys_errlist == NULL) {

I'm debugging this code :

len = NGX_SYS_NERR * sizeof(ngx_str_t);

ngx_sys_errlist = malloc(len);
if (ngx_sys_errlist == NULL) {
    goto failed;
}

for (err = 0; err < NGX_SYS_NERR; err++) {

But in gdb if (ngx_sys_errlist == NULL) { is skippe开发者_运维技巧d directly:

(gdb) 
59      ngx_sys_errlist = malloc(len);
(gdb) n
64      for (err = 0; err < NGX_SYS_NERR; err++) {

I also have experienced this before,but never knows the reason,anyone knows?

Is it a bug?

UPDATE

0x000000000041be9d <ngx_strerror_init+0>:   mov    %rbx,-0x30(%rsp)
0x000000000041bea2 <ngx_strerror_init+5>:   mov    %rbp,-0x28(%rsp)
0x000000000041bea7 <ngx_strerror_init+10>:  mov    %r12,-0x20(%rsp)
0x000000000041beac <ngx_strerror_init+15>:  mov    %r13,-0x18(%rsp)
0x000000000041beb1 <ngx_strerror_init+20>:  mov    %r14,-0x10(%rsp)
0x000000000041beb6 <ngx_strerror_init+25>:  mov    %r15,-0x8(%rsp)
0x000000000041bebb <ngx_strerror_init+30>:  sub    $0x38,%rsp
0x000000000041bebf <ngx_strerror_init+34>:  mov    $0x840,%edi
0x000000000041bec4 <ngx_strerror_init+39>:  callq  0x402388 <malloc@plt>
0x000000000041bec9 <ngx_strerror_init+44>:  mov    %rax,0x26e718(%rip)        # 0x68a5e8 <ngx_sys_errlist>
0x000000000041bed0 <ngx_strerror_init+51>:  mov    $0x840,%r12d
0x000000000041bed6 <ngx_strerror_init+57>:  test   %rax,%rax
0x000000000041bed9 <ngx_strerror_init+60>:  je     0x41bf56 <ngx_strerror_init+185>
0x000000000041bedb <ngx_strerror_init+62>:  mov    $0x0,%r13d
0x000000000041bee1 <ngx_strerror_init+68>:  mov    $0x0,%r14d
0x000000000041bee7 <ngx_strerror_init+74>:  mov    $0x0,%r15d
0x000000000041beed <ngx_strerror_init+80>:  mov    %r13d,%edi
0x000000000041bef0 <ngx_strerror_init+83>:  callq  0x402578 <strerror@plt>

UPDATE

Nobody else ever met the same thing in using gdb? It happens to me frequently when debugging.


Most likely the two statements were optimized into a single set-and-test expression, which then can't be decomposed into the original two lines. The generated pseudocode is likely to be something like

call _malloc
jz _failed
mov acc, _ngx_sys_errlist

where the test now happens before the assignment; do you let the source level trace go backwards to reflect this?


please check,
a) if you are debugging release build (if there exists one)
b) if your source file is modified

if you still have the issue, please provide the details (Complier with version, degugger version , platform and code ...)

0

精彩评论

暂无评论...
验证码 换一张
取 消