[lttng-dev] Bug in LTTng-UST

Simon Marchi simon.marchi at polymtl.ca
Fri Dec 12 23:21:23 EST 2014

Actually, I think the problem comes from UST not handling when a
program dlcloses a lib. There is a simpler way to show the problem.
Just have an app dlopen a .so that has a tracepoint and dlclose it.
When the app quits, UST will try to unregister the tracepoint and
read/write in the memory previously mapped to the library, causing a

I have made a small example. You just need to click on "Download gist"
in [1] to download a tarball, and a then simple make should be enough.
Start a UST session with -u -a and run ./app. Segfault should ensue.

[1] https://gist.github.com/simark/9fc0e2395899fcd8d10d

On 12 December 2014 at 19:54, Matthew Khouzam
<matthew.khouzam at ericsson.com> wrote:
> Hi, it appears as though if a tracepoint is in a so, loading it,
> unloading it and reloading it makes it no longer visible.
> To confirm this you can try out this repo :
> https://github.com/TheMatthew/yquake2
> (I know, it's not a serious program... but the bug is serious, I think)
> You can get the demo files here
> http://www.fileplanet.com/6584/0/fileinfo/Quake-2-Demo-v3.14
> make the program (make from the git dir)
> copy the contents of the baseq2 in the demo into the release/baseq2
> directory
> start a ust session
> run the program.
> Ignore the baddr deadlocks :)
> The tracepoint is not visible, it is located in the game.so file.
> Chances are though that the problem is on my side, but the evidence
> (single registration ) seems to indicate that this is an actual problem.
> _______________________________________________
> lttng-dev mailing list
> lttng-dev at lists.lttng.org
> http://lists.lttng.org/cgi-bin/mailman/listinfo/lttng-dev

More information about the lttng-dev mailing list