On 5/4/2012 1:33 AM, John Morris wrote:
> 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?
I honestly have no idea about the writes to the stderr structs and what
would be 'normal'. This could easily be a red herring.
> 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.)
Hitting the "electric fence" seems more likely to be a real problem, but
I'm not familiar enough with the glibc library and C to crawl through
the code or determine if this is a root cause or just another
down-stream side-effect of the initial issue (most likely memory
corruption).
--
Charles Steinkuehler
[email protected]
------------------------------------------------------------------------------
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
