libtraceevent and threads

libtraceevent and threads

[Felipe Balbi]

[-- Attachment #1: Type: text/plain, Size: 991 bytes --]


Hi,

I was playing with binding `libtraceevent' to rust today. Generating the
bindings with rust's `bindgen' is very straight forward. When I moved to
porting the existing tests to rust, I found out that running a single
test always worked, while running all tests caused random allocation
failures and (apparent) corruption of the trace_seq buffer.

Upon further investigating the issue, I noticed that asking `cargo' to
run tests in a single thread (essentially one test at a time), always
gave me good results, but as soon as I let `cargo' run 2 threads (or
more) failures would show.

I appears that this is because `libtraceevent' keeps some global state
and that prevents different threads to keep their own "context" of the
library.

I can't say for sure, but it seems that the culprit here is:

	static const char *input_buf;

in line 31 of src/event-parse.c. Would there be a way to hide that
perhaps as part of `struct tep_handle'?

cheers

-- 
balbi

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 857 bytes --]

Re: libtraceevent and threads

[Steven Rostedt]

On Thu, 15 Dec 2022 19:42:32 +0200
Felipe Balbi <balbi@kernel.org> wrote:

> Hi,
> 
> I was playing with binding `libtraceevent' to rust today. Generating the
> bindings with rust's `bindgen' is very straight forward. When I moved to
> porting the existing tests to rust, I found out that running a single
> test always worked, while running all tests caused random allocation
> failures and (apparent) corruption of the trace_seq buffer.
> 
> Upon further investigating the issue, I noticed that asking `cargo' to
> run tests in a single thread (essentially one test at a time), always
> gave me good results, but as soon as I let `cargo' run 2 threads (or
> more) failures would show.
> 
> I appears that this is because `libtraceevent' keeps some global state
> and that prevents different threads to keep their own "context" of the
> library.
> 
> I can't say for sure, but it seems that the culprit here is:
> 
> 	static const char *input_buf;
> 
> in line 31 of src/event-parse.c. Would there be a way to hide that
> perhaps as part of `struct tep_handle'?

Ah sure. I think we discovered this once before and was meaning to change
it. There may have been issues where we needed to design things
differently. I don't recall.

But if you want to send patches to move that to the tep handle and make it
work, I'm all for it.

-- Steve