Stephan Zimmermann wrote: > I wasn't able to isolate the section of my code that causes the crash by > now. The only thing I figured out by now is that the particular crash > does not happen with 2.3.x rev 2077. > So I guess some change from 2077 to the 2139 revision did break something.
Could you track the issue a bit more down? There are not to many "interesting" changes to 2.3.x. A few milestones I found in the ChangeLog: - 2092: Allow sleeping scheduler locks - 2108: Before RPI rework Anything after 2108 only makes sense to dissect when you switch on XENO_OPT_RPIDISABLE (RPI was buggy until 2139). > I'll go on trying to make it reproducible in a small demo program. > > By the way, I see a Pentium M crash reliable when I do the following, > don't know if it's related: > > - load nucleus and native module > - start / stop my app > - reload the modules > - start my app --> crash > > I attached 'screenshots' of a total freeze with backtrace and some > messages I extracted from syslog (both on Pentium M). Looks like some memory corruption. Your application is not messing around on raw (kernel) memory and/or hardware? Keep in mind that changes to the kernel code also moves offsets, potentially unrevealing a pre-existing corruption that so far just hit harmless regions. Jan
signature.asc
Description: OpenPGP digital signature
_______________________________________________ Xenomai-help mailing list [email protected] https://mail.gna.org/listinfo/xenomai-help
