kern/122082: [in_pcb] NULL pointer dereference in in_pcbdrop
Jari Kirma
kirma at cs.hut.fi
Fri Oct 31 06:34:11 PDT 2008
On Fri, 31 Oct 2008, rwatson at FreeBSD.org wrote:
> Synopsis: [in_pcb] NULL pointer dereference in in_pcbdrop
>
> State-Changed-From-To: open->feedback
> State-Changed-By: rwatson
> State-Changed-When: Fri Oct 31 12:52:03 UTC 2008
> State-Changed-Why:
> Could I ask you to confirm whether this still occurs with the most recent
> 7-STABLE? If so, could I then ask you to print *tw and *inp in the
> tcp_twclose frame, which might shed a bit more light on things.
>
> Thanks!
Unfortunately I don't have this kind of spare machine to risk crashing,
although I try to look at it again. Still, if I remember correctly, the
system was agitated to crash very often (like over 25% of time after
bootup in some 15 first minutes): linux-opera (or even linux-firefox)
being used actively on a quad-core machine running relatively regular xfce
desktop. When the system survived first fifteen minutes or so, it seemed
to get less and less likely it would crash similarly, although it could
have happened weeks after that with very similar signs: crashing a moment
after browsing around, as if remote teardown of a persistent HTTP TCP
socket from the remote end would trigger it.
I think the Linux emulation part in this context is somehow significant.
When I moved to native Firefox instead, at least similar crashes ceased to
occur. Might there be some locks not being held on Linux call path in
comparison to native versions?
> Responsible-Changed-From-To: freebsd-net->rwatson
> Responsible-Changed-By: rwatson
> Responsible-Changed-When: Fri Oct 31 12:52:03 UTC 2008
> Responsible-Changed-Why:
> Could I ask you to confirm whether this still occurs with the most recent
> 7-STABLE? If so, could I then ask you to print *tw and *inp in the
> tcp_twclose frame, which might shed a bit more light on things.
>
> Thanks!
>
>
> http://www.freebsd.org/cgi/query-pr.cgi?pr=122082
>
More information about the freebsd-net
mailing list