Hi Charles,
> I haven't been able to get the record feature of gdb to do much of
> anything useful, because it keeps stopping on an unsupported instruction
> (0xc5). I don't know if this is related to the crashing or not. :-/
I spent a good 10 hours on this and have narrowed things down to
weirdness, as well. Using the technique I described, I traced the
segfault into malloc.c. I had to do a bunch of reading to understand
malloc's data structures before I could see the problem, and when I
finally did, no luck.
Recycled memory chunks are split for a new malloc(), one part given to
the program, the remainder put back into a 'bin' in a circular
doubly-linked list for later use. I could step back and forth across
this instruction here:
remainder->bk = bck;
'bck' has a valid non-NULL value, but remainder->bk is assigned NULL.
This isn't an optimizer thing, since the value *does* change there, and
it stays NULL until later in the program when it causes the segfault.
My only thought about the cause is funkiness with gdb record and
multi-threadedness, which would put me back at square one. I suppose
your 'unsupported instruction' problem could be caused by the same kind
of corrupt pointers into code, but it looks like the record feature
would have the same limitations.
I did find an old patch to enable gdb record with threads, but I've
already got my hands full resurrecting old patches. ;) Unless anyone
has some other good idea, I think I hit a dead end with this one.
> I was, however, able to turn up what might be a useful clue using
> electric fence. I used the .gdbinit example from the debian package,
> which sets two environment variables prior to running rtapi_app:
>
> set environment EF_PROTECT_BELOW 1
> set environment LD_PRELOAD /usr/lib/libefence.so.0.0
>
> When run this way, the application *ALWAYS* segfaults on line 131 of
> linux_rtapi.c: the call to rtapi_print_msg call in the
> rtapi_reset_pagefault_count function (although it is the vfprintf in
> default_rtapi_msg_handler that is actually causing the segfault).
>
> I still don't know _why_ this is happening, but it feels like at least
> the root issue may be getting closer to the surface.
Ahhh, just in the nick of time to save me from the pit of despair, a
fresh path. Thank you Charles!
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
