Hi Charles,
>> If you run with electric fence, you'll get a segfault well before the
>> malloc crash, where one of the debug writes to stderr is stepping on
>> memory that it shouldn't (which is likely what is eventually causing
>> malloc to barf). Looking at what might be corrupting the stderr
>> structure is what lead me to point the finger at the rtapi_print_msg
>> from rtapi_clock_set_period.
Nice tool. It'll also handle locking, instead of recycling, freed pages
by setting this in gdb:
set environment EF_PROTECT_FREE=1
Anyway, I got the same result you did with EF.
I'm not clear what the 'watch' you're setting on *stderr is for. The
'stderr' pointer points to the first word of stderr's _IO_FILE struct,
'_flags':
(gdb) p stderr
$75 = (struct _IO_FILE *) 0x39fc5b2160
(gdb) p *stderr
$76 = {_flags = -72537977, _IO_read_ptr = 0x39fc5b21e3 "", [blah blah]}
In your gdb listing, the watch point detects the value of stderr->_flags
changing twice; should that not happen normally?
The segfault occurs in vfprintf.c:1278 on my system:
f = lead_str_end = __find_specmb ((const UCHAR_T *) format);
(At this point, it hasn't tried to write to stderr yet; it's still
computing the output.)
'format' is the pointer to '*fmt' from rtapi_print_msg, and looks just
fine from gdb. 'f' and 'lead_str_end' are just (char *) pointers. I'm
unable to expand the __find_specmb macro with all the -debug and
-debuginfo RPMs that seemed related, so I'm rebuilding the glibc RPM to
see what the heck that thing is. Odds on that being a red herring?
> Just wanted to say I'm going to be going off-line for a while (until
> next Wednesday). I'll have e-mail, but no access to a development platform.
Good for you, take a step back. From all the emails about ice cream
cones, guns that shoot both forward and backward, turning screws, etc. I
think this thing might be making others as delirious as me!
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
