Philippe Gerum wrote: > Jan Kiszka wrote: > > Philippe, > > > > you recently said there is a bug in the x86_64 support when syscall > > tracing is enabled. Now I think I stepped on it as well: In order to > > validate my APIC frequency patches for that arch, I wanted to use LTTng > > there. But as soon as I start the trace, the latency test fails to run, > > prematurely exiting due to a segfault. > > Exactly what Gilles sees on his box too, latency segfaulting at startup. > On mine, the kernel does not even boot. > > Gdb and the kernel say that user > > land jumped to address 0, I just yet failed to find out where they come > > from. I strongly assume LTTng enables syscall tracing, because its > > entry/exit instrumentations are inside the hook function > > (syscall_trace_entry/leave). > > > > Do you have any further details on your tracing issue? Does may > > observation correlates with yours? > > Quite frankly, I did not dig the issue that far yet, but yes, my first > impression is that something is broken in the syscall return path (or > entry?), and it shows when the return path to user-space is diverted in > some way, either for security auditing, or likely for tracing like > you've just reported.
>From what I have read in some comments, the syscall auditing function kmallocs some memory that is kfreed on syscall return. Obviously, this can not work with Xenomai. -- Gilles Chanteperdrix. _______________________________________________ Xenomai-core mailing list Xenomaiemail@example.com https://mail.gna.org/listinfo/xenomai-core