[Crash-utility] Unable to switch stack frames while using crash
Andrew Suffield
asuffield at acunu.com
Sat Jun 25 15:31:26 UTC 2011
On 24 June 2011 15:29, Dave Anderson <anderson at redhat.com> wrote:
> Yeah, although the contents tty->read_buf are hard to explain.
> It gets allocated during n_tty_open() and freed during n_tty_close().
> And at the beginning of n_tty_read() there's:
>
> BUG_ON(!tty->read_buf);
>
> and the dump-time contents show a buffer allocated:
>
> crash> tty_struct ffff8802cbd54800
> struct tty_struct { ...
> magic = 21505,
> driver = 0xffff88031b54ea00,
> ops = 0xffffffff8130f650,
> name = "pts9\000\...",
> driver_data = 0xffff88029c8a9668,
> icanon = 1 '\001',
> read_buf = 0xffff8802cbfe6000 "",
> read_head = 0,
> read_tail = 0,
> read_cnt = 0,
> ...
>
> but it's a NULL pointer when read during the function?
>
>
Hmm, that is interesting. Assuming that we are in fact dealing with a
software bug where this memory area changed recently, the only possible
explanation I can see is that n_tty_close() has been called while
n_tty_read() is in progress. I know that's not supposed to happen, but the
implication would be that is the bug - a locking issue in the tty layer that
allows them to be closed while calls are in progress. Sadly that code isn't
as mature as it should be and there was a whole load of concurrency issues
fixed in the late 2.6.30s; I don't know the details, but it might be one of
those.
Alternatively it's regular old hardware failure and we're just looking at
junk.
I think that's about as far as we can go on the information available (and
also the extent to which it's relevant to this mailing list)
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://listman.redhat.com/archives/crash-utility/attachments/20110625/dd04f7be/attachment.htm>
More information about the Crash-utility
mailing list