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
Xenomai-core@gna.org
https://mail.gna.org/listinfo/xenomai-core

Reply via email to