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

[Mathieu Desnoyers]

----- Original Message -----

> From: "zhenyu.ren" <zhenyu.ren at aliyun.com>
> To: "Mathieu Desnoyers" <mathieu.desnoyers at efficios.com>, "David Goulet"
> <dgoulet at efficios.com>
> Cc: "lttng-dev" <lttng-dev at lists.lttng.org>
> Sent: Tuesday, October 22, 2013 4:49:19 AM
> Subject: 答复: 答复: lttng list -u coredump

> > Therefore, the &(pos)->member != NULL check will break out of the loop
> > immediately,

> As you pointed out,pos is a very large pointer value(i.e
> 0xffffffffffffff88,say an invalid pointer) . Before check itself,
> &(pos)->member has been deferenced anyway.

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. 

I'm concerned that focusing on the hash table iteration might be leading us in the wrong direction. What we see in the information you provided is a an error detected by glibc "free()", which seems much more likely to point to the culprit. However, we'd need more information about the symbols in this backtrace. 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. 

Thanks, 

Mathieu 

> > Please provide details about the lttng-tools, lttng-ust, lttng-modules,
> > userspace RCU versions you are using

> lttng-tools,lttng-ust and lttng-modules are 2.3.0,userspace RCU is 0.8.0

> thanks
> zhenyu.ren

-- 
Mathieu Desnoyers 
EfficiOS Inc. 
http://www.efficios.com 
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.lttng.org/pipermail/lttng-dev/attachments/20131022/662b87c4/attachment-0001.html>