Right, back from away.
John:
You answered my question quite adequately. And I referred to
PREEMPT_RT when writing RT. Jus t my fingers are so thick.
All:
I seem to miss the stacktrace leading up to the crash in the
reports. So, sadly, there is little help I can offer since you guys are
all so wrapped up in the idea that there is perhaps an underlying problem
in the kernel or in glibc. In my debuggerless experience, however, the
fault is in 99% of all cases in the newly written code (a.k. the diff I
produced) So is it possible to get a few stacktraces please? And from what
you guys describe I still think there is a process lock problem with
variables that dont seem to update! That we will only see when we analise
the code. The debugger is only in the way, trying to find those (at least
in my experience).
So now since it is friday afternoon lets have a small intermediate beer, to
get the spirits up again ;) Maybe if we lubricate the electrons a bit
things will become clearer.
Cheers
j.
On Fri, May 4, 2012 at 3:42 PM, Charles Steinkuehler <
char...@steinkuehler.net> wrote:
> 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
> char...@steinkuehler.net
>
>
> ------------------------------------------------------------------------------
> 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
