Hi Charles,
> I have verified that the "fix" works not just immediately after the
> 8868436313c34eaf60a14f5c930f0f2035b9ee48 commit, but also on HEAD with
> the bitopts-fix patch.
Yep, it's 'working' for me, too.
> Interestingly, even when I send all rtapi output to stdout, I am
> *STILL* not seeing any of the expected rtapi_msg_handler messages on
> the console. I _really_ think this is the core issue, and moving
> messages from stderr to stdout just avoids the crash (or more likely
> delays it until much later).
I tried to add a little extra output to the messages in
default_rtapi_msg_handler, and things broke again for no apparent
reason. I agree that there's some funky issue that we haven't really
identified or fixed.
> It seems like this may have been a bug in the linux-preempt_rt patches
> for some time, but for whatever reason didn't cause serious problems
> until the changes to the rtapi output scheme.
That sounds right on. The rtapi output scheme code is pretty much
copied and pasted from the simulator, so the problem's most likely in
the ~1300 lines Michael Buesch touched.
> Well, as a rule I never turn down free beer, but I'm not sure it's
> deserved in this case. Instead of a programmer or engineer, I feel
> more like a nuclear physicist playing with genetic algorithms: blowing
> things up and trying to figure out what happened based on the
> resulting pieces...then if it doesn't make sense I randomly change
> something and blow it up again. :)
Ha, I like the comparison. I also think the underlying problem isn't
fixed, but I'll extend the bounty another week, to include 'information
leading to the apprehension and squashing of the bug', and to multiple
list subscribers. Yipee!
John
------------------------------------------------------------------------------
Live Security Virtual Conference
Exclusive live event will cover all the ways today's security and
threat landscape has changed and how IT managers can respond. Discussions
will include endpoint security, mobile security and the latest in malware
threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
_______________________________________________
Emc-developers mailing list
Emc-developers@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/emc-developers
