[lttng-dev] 答复: 答复: 答复: lttng list -u coredump

[zhenyu.ren]

>Can you point out what in the C99 specification makes you believe that the pointer is actually dereferenced in the expression "&(pos)->member" ?>AFAIK, this only evaluates to the address of field "member" within "pos". The compiler should not dereference the pointer "pos" at all.
Yes,you are right.

> Probably that getting it with a lttng-sessiond compiled with "-g -O0" (no optimisations, with debug symbols) would help us make more sense out of the free() error output. Everything is ok f lttng-sessiond compiled with "-O0",so it looks like a compiler issue.with -O2 disassemble ust_app_list_events()0x0000000000418821 <ust_app_list_events+49>:    callq  0x403f60 <rcu_read_lock_memb at plt>
0x0000000000418826 <ust_app_list_events+54>:    mov    0x2441ab(%rip),%rax        # 0x65c9d8 <ust_app_ht>
0x000000000041882d <ust_app_list_events+61>:    lea    0x230(%rsp),%rsi
0x0000000000418835 <ust_app_list_events+69>:    mov    (%rax),%rdi
0x0000000000418838 <ust_app_list_events+72>:    callq  0x403ba0 <lttng_cds_lfht_first at plt>
0x000000000041883d <ust_app_list_events+77>:    mov    $0xffffffffffffffc8,%rax
0x0000000000418844 <ust_app_list_events+84>:    add    %fs:0x0,%rax
0x000000000041884d <ust_app_list_events+93>:    mov    0x230(%rsp),%rbp         //app->pid_n.node
0x0000000000418855 <ust_app_list_events+101>:   movq   $0x20,0x28(%rsp)
0x000000000041885e <ust_app_list_events+110>:   movq   $0x0,0x30(%rsp)
0x0000000000418867 <ust_app_list_events+119>:   movq   $0x0,0x18(%rsp)
0x0000000000418870 <ust_app_list_events+128>:   add    $0x18,%rax
0x0000000000418874 <ust_app_list_events+132>:   sub    $0x78,%rbp               //app
0x0000000000418878 <ust_app_list_events+136>:   mov    %rax,0x38(%rsp)          //inside loop
0x000000000041887d <ust_app_list_events+141>:   nopl   (%rax)
0x0000000000418880 <ust_app_list_events+144>:   mov    0x38(%rsp),%rax
0x0000000000418885 <ust_app_list_events+149>:   lock addq $0x2,(%rax)
0x000000000041888a <ust_app_list_events+154>:   mov    0x34(%rbp),%eax          //app->compatible
0x000000000041888d <ust_app_list_events+157>:   test   %eax,%eax
0x000000000041888f <ust_app_list_events+159>:   je     0x418a00 <ust_app_list_events+528>
0x0000000000418895 <ust_app_list_events+165>:   mov    0x0(%rbp),%edi
0x0000000000418898 <ust_app_list_events+168>:   callq  0x4036f0 <ustctl_tracepoint_list at plt>
0x000000000041889d <ust_app_list_events+173>:   test   %eax,%eax
  As you may see,nothing can prevent cpu from walking inside loop even if app is an invalid pointer.It seems the  compiler（GCC 4.1.2 20080704） always think &(pos)->member!=NULL. with -O0 disassemble ust_app_list_events()0x000000000041c649 <ust_app_list_events+180>:   callq  0x404018 <rcu_read_lock_memb at plt>
0x000000000041c64e <ust_app_list_events+185>:   mov    0x243ee3(%rip),%rax        # 0x660538 <ust_app_ht>
0x000000000041c655 <ust_app_list_events+192>:   mov    (%rax),%rdi
0x000000000041c658 <ust_app_list_events+195>:   lea    -0x70(%rbp),%rsi
0x000000000041c65c <ust_app_list_events+199>:   callq  0x403c48 <lttng_cds_lfht_first at plt>
0x000000000041c661 <ust_app_list_events+204>:   lea    -0x70(%rbp),%rdi
0x000000000041c665 <ust_app_list_events+208>:   callq  0x41701e <cds_lfht_iter_get_node>
0x000000000041c66a <ust_app_list_events+213>:   mov    %rax,-0x30(%rbp)         //app->pid_n.node
0x000000000041c66e <ust_app_list_events+217>:   mov    -0x30(%rbp),%rax
0x000000000041c672 <ust_app_list_events+221>:   sub    $0x78,%rax               //app
0x000000000041c676 <ust_app_list_events+225>:   mov    %rax,-0x48(%rbp)
0x000000000041c67a <ust_app_list_events+229>:   jmpq   0x41c9db <ust_app_list_events+1094>      //&(app)->pid_n.node!=NULL
0x000000000041c67f <ust_app_list_events+234>:   callq  0x418582 <health_code_update>            //inside loop
0x000000000041c684 <ust_app_list_events+239>:   mov    -0x48(%rbp),%rax
0x000000000041c688 <ust_app_list_events+243>:   mov    0x34(%rax),%eax
0x000000000041c68b <ust_app_list_events+246>:   test   %eax,%eax
0x000000000041c68d <ust_app_list_events+248>:   je     0x41c9af <ust_app_list_events+1050>
0x000000000041c693 <ust_app_list_events+254>:   mov    -0x48(%rbp),%rax
0x000000000041c697 <ust_app_list_events+258>:   mov    (%rax),%edi
...
0x000000000041c9db <ust_app_list_events+1094>:  mov    -0x48(%rbp),%rax   //app--(pos)
0x000000000041c9df <ust_app_list_events+1098>:  add    $0x78,%rax                //app->pid_n.node --(pos->member)
0x000000000041c9e3 <ust_app_list_events+1102>:  test   %rax,%rax
0x000000000041c9e6 <ust_app_list_events+1105>:  jne    0x41c67f <ust_app_list_events+234>
In this case,the compiler will do checking at 0x000000000041c9e3 that is missed in the previous case.Thankszhenyu.ren
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.lttng.org/pipermail/lttng-dev/attachments/20131023/6fe41941/attachment-0001.html>