On 16/01/15 11:17, Ian Jackson wrote:
> The latter is the GPF turning out to be unreproducible.
>
> I guess we should keep an eye out in case it turns out to be a race
> rather than a cosmic ray.
I do not believe in cosmic rays.
Some notes in case it resurfaces:
1) the topmost caller address appears to be on the stack (??)
2) "calling main()" seems to be output properly, the next line ("running
demos") doesn't. there is exactly one function call (~20 instructions)
between these two lines
3) the first printf goes to stderr, while the second, supposedly failing
one, goes to stdout (no idea why)
4) it's crashing calling fp->_swrite(). notably, the execution of
__sflush() might or might not go that far if fp upon entry points to
garbage (existing garbage, not page faulting garbage)
5) the call is made as:
6018b: 41 ff 54 24 50 callq *0x50(%r12)
from the output:
R12: 000000000000e02b
(e02b is somewhere in the middle of xenbus_xb_write, highly unlikely to
be relevant, more likely to be some random garbage)
from the image:
rump-kernel$ nm rump-kernel | grep __sF
0000000000299d60 D __sF
(stdout is __sF[1])
There are no (user) threads active yet. I currently have no theories
how the failure is reachable, at least assuming that the console output
is accurate. I still don't believe in cosmic rays, though ;)
------------------------------------------------------------------------------
New Year. New Location. New Benefits. New Data Center in Ashburn, VA.
GigeNET is offering a free month of service with a new server in Ashburn.
Choose from 2 high performing configs, both with 100TB of bandwidth.
Higher redundancy.Lower latency.Increased capacity.Completely compliant.
http://p.sf.net/sfu/gigenet
_______________________________________________
rumpkernel-users mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/rumpkernel-users
