[ltt-dev] Assert error ust strncpy

[ltt-dev] Assert error ust strncpy

[David Goulet]

Hi Mathieu,

I have a quite big problem since the new patch with strncpy for UST.

With a high number of events (100000 +), I got this :

buffers.h:525: ust_buffers_write: Assertion `buf_offset + len < 
buf->chan->subbuf_size*buf->chan->subbuf_cnt' failed.

At that line in (libust/buffers.h) you have two asserts and the first 
one seems not needed because the second assert check the exact same 
thing with "len" added... but still apply for the case of the first one.

Anyway, is this means that the subbuffers are full? I'm actually in 
OVERWRITE mode so... why does the tracing stop there?

Test case (tar.gz) in attachment. Tested on 2 separate machines.

UST_TRACE=1 UST_AUTOPROBE=1 UST_OVERWRITE=1 UST_AUTOCOLLECT=0 
./withtracepoint 1 10000000

Thanks
-- 
David Goulet
LTTng project, DORSAL Lab.

PGP/GPG : 1024D/16BD8563
BE3C 672B 9331 9796 291A  14C6 4AF7 C14B 16BD 8563
-------------- next part --------------
A non-text attachment was scrubbed...
Name: ust-error-test.donut
Type: application/octet-stream
Size: 3365 bytes
Desc: not available
URL: <http://lists.casi.polymtl.ca/pipermail/lttng-dev/attachments/20100817/71f54b51/attachment-0002.obj>

[ltt-dev] Assert error ust strncpy

[David Goulet]

Hi Mathieu,

I have a quite big problem since the new patch with strncpy for UST.

With a high number of events (100000 +), I got this :

buffers.h:525: ust_buffers_write: Assertion `buf_offset + len < 
buf->chan->subbuf_size*buf->chan->subbuf_cnt' failed.

At that line in (libust/buffers.h) you have two asserts and the first 
one seems not needed because the second assert check the exact same 
thing with "len" added... but still apply for the case of the first one.

Anyway, is this means that the subbuffers are full? I'm actually in 
OVERWRITE mode so... why does the tracing stop there?

Test case (tar.gz) in attachment. Tested on 2 separate machines.

UST_TRACE=1 UST_AUTOPROBE=1 UST_OVERWRITE=1 UST_AUTOCOLLECT=0 
./withtracepoint 1 10000000

Thanks
-- 
David Goulet
LTTng project, DORSAL Lab.

PGP/GPG : 1024D/16BD8563
BE3C 672B 9331 9796 291A  14C6 4AF7 C14B 16BD 8563
-------------- next part --------------
A non-text attachment was scrubbed...
Name: ust-error-test.donut
Type: application/octet-stream
Size: 3365 bytes
Desc: not available
URL: <http://lists.casi.polymtl.ca/pipermail/lttng-dev/attachments/20100817/71f54b51/attachment-0003.obj>

[ltt-dev] Assert error ust strncpy

[David Goulet]

Hi Mathieu,

I have a quite big problem since the new patch with strncpy for UST.

With a high number of events (100000 +), I got this :

buffers.h:525: ust_buffers_write: Assertion `buf_offset + len < 
buf->chan->subbuf_size*buf->chan->subbuf_cnt' failed.

At that line in (libust/buffers.h) you have two asserts and the first 
one seems not needed because the second assert check the exact same 
thing with "len" added... but still apply for the case of the first one.

Anyway, is this means that the subbuffers are full? I'm actually in 
OVERWRITE mode so... why does the tracing stop there?

Test case (tar.gz) in attachment. Tested on 2 separate machines.

UST_TRACE=1 UST_AUTOPROBE=1 UST_OVERWRITE=1 UST_AUTOCOLLECT=0 
./withtracepoint 1 10000000

Thanks
-- 
David Goulet
LTTng project, DORSAL Lab.

PGP/GPG : 1024D/16BD8563
BE3C 672B 9331 9796 291A  14C6 4AF7 C14B 16BD 8563
-------------- next part --------------
A non-text attachment was scrubbed...
Name: ust-error-test.donut
Type: application/octet-stream
Size: 3365 bytes
Desc: not available
URL: <http://lists.casi.polymtl.ca/pipermail/ltt-dev/attachments/20100817/71f54b51/attachment.obj>

[ltt-dev] Assert error ust strncpy

[Mathieu Desnoyers]

* David Goulet (david.goulet at polymtl.ca) wrote:
> Hi Mathieu,
>
> I have a quite big problem since the new patch with strncpy for UST.
>
> With a high number of events (100000 +), I got this :
>
> buffers.h:525: ust_buffers_write: Assertion `buf_offset + len <  
> buf->chan->subbuf_size*buf->chan->subbuf_cnt' failed.
>
> At that line in (libust/buffers.h) you have two asserts and the first  
> one seems not needed because the second assert check the exact same  
> thing with "len" added... but still apply for the case of the first one.

If the first fails, then we know the the value fails, then then second, we know
it's len that makes it fail. It's not useless.

I found the problem. Off by one in my assert. Will post a patch in a jiffy.

Thanks,

Mathieu

>
> Anyway, is this means that the subbuffers are full? I'm actually in  
> OVERWRITE mode so... why does the tracing stop there?
>
> Test case (tar.gz) in attachment. Tested on 2 separate machines.
>
> UST_TRACE=1 UST_AUTOPROBE=1 UST_OVERWRITE=1 UST_AUTOCOLLECT=0  
> ./withtracepoint 1 10000000
>
> Thanks
> -- 
> David Goulet
> LTTng project, DORSAL Lab.
>
> PGP/GPG : 1024D/16BD8563
> BE3C 672B 9331 9796 291A  14C6 4AF7 C14B 16BD 8563



-- 
Mathieu Desnoyers
Operating System Efficiency R&D Consultant
EfficiOS Inc.
http://www.efficios.com