Brian L. wrote: > I'm finally set up with netconsole to catch panics/crashes when they > happen so now I can report more information on the one I alluded to a > week or two ago in my "General Question.." thread. > > What I did to cause it was write past the end of a buffer returned by > rt_queue_alloc. I'm not entirely sure if this message came at the > moment of the write (unlikely, IMHO) or later when more xnheap > activity took place. The crash popped up in several different ways > depending on what code paths I enabled/disabled. > > What concerns me is that polluting an xnheap can bring the system to > its knees so harshly. I can see why it could be *very* hard to police > this sort of problem without destroying the performance of xnheap, so > it wouldn't surprise me if this is "normal". Still, though, it's sad > that user-space code can bring the system down after something as > innocent as a fencepost error in a string copy routine... > > Thoughts? I've pasted the console dump below. >
I remember that control structures and data are tightly knotted in xnheaps, but I agree with you that this should not lead so easily to such crashes for user space apps. Maybe some magic number check could help to reduce the chance for now. A cleaner long-term solution would be to decouple both regions. Philippe, is this feasible (I'm not that deep in the internals of xnheap)? Jan
signature.asc
Description: OpenPGP digital signature
_______________________________________________ Xenomai-help mailing list [email protected] https://mail.gna.org/listinfo/xenomai-help
