Hi Jan,
> This is what happens when you sleep late every day: The sun starts to get
> slow also! In Africa we get up early, so we get to drink the beer early! As
> the sun gets hot, that is the right time.
Africa, not Europe, sorry. Not quite like Africa, but in Texas, the sun
gets hot, and we drink beer, and *everything* gets slow.
> John: Are we still convinced that the system ran before you gitdiffed the
> offending commit out?
I'm not sure what you mean here, do you mean reversing funny.patch on
HEAD and doing more testing? That's an interesting idea.
We (Charles confirmed) are convinced that pre-funny.diff, the system
*ran*. Whether there was an untickled bug at that point, we don't know,
but that was the last version that ran as is.
Post-funny.diff, the bug is confirmed to be there, and causes segfaults
unless you apply Charles's patch that directs output to stdout rather
than stderr. With his patch, the system seems to run as well as
pre-funny.diff.
------------------------------
Anyway, here's what I know, with a few advances:
Using Charles's Electric Fence setup, he and I both get reliable
segfaults at linux_rtapi.c:131, in the function rtapi_reset_pagefault_count.
Thread 1 creates the new thread at this line, linux_rtapi.c:560:
> retval = pthread_create(&task->thread, &attr, realtime_thread, (void *)task);
(It's helpful, by the way, to prevent the other thread from running
while you're mucking around with this gdb command: set
scheduler-locking on)
In thread 1, either before or after that statement, the gdb command
'print fprintf(stderr, "more beer please!\n")' works fine.
Switch to thread 2, the gdb command will always segfault.
The reason 'printf("more beer NOW\n")' doesn't segfault is because
stdout is an unbuffered _IO_FILE (try p stderr->_flags & 2) whereas
stderr is, so printf skips the whole 'buffered_*printf' business we've
seen in the segfault stack traces (Charles's gdb.rtapi_app.ef.txt is an
example).
So, I still don't know the cause of all this, but this narrows it down a
bit more, I hope.
My suspicions are one of the following is true (certainly the last):
- thread 2's stack isn't being allocated correctly somehow
- stderr needs to be put into buffered mode, if that makes sense and is
possible
- I'm still clueless and need to do a bunch more reading. :P
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
[email protected]
https://lists.sourceforge.net/lists/listinfo/emc-developers
