I'm completely nackered, and once I get to bed for a nap I will completely forget about this (ans I have over 1100 emails in my inbox, so putting it off is just off putting)...
Usually when malloc wedges up like this it is caused by just a coupe of things 1) a double free of the same allocated block, 2) writing past the end of a block, or 3) freeing up memory that was allocated by one process but still accessing it in a different one. Anyway that is my personal experience. YMMV. If that is the problem, good luck finding that. If you do I'll buy you a beer, pot of tea, or ice-cream cone (you name your favorite poison) EBo -- On Thu, 03 May 2012 16:43:11 -0500, John Morris wrote: > 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 ------------------------------------------------------------------------------ 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
