Re: libtraceevent and threads

[Steven Rostedt <rostedt@goodmis.org>]

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