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 segfault.
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 <[email protected]> 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 > [email protected] > http://lists.lttng.org/cgi-bin/mailman/listinfo/lttng-dev _______________________________________________ lttng-dev mailing list [email protected] http://lists.lttng.org/cgi-bin/mailman/listinfo/lttng-dev
