Date: Fri, 15 Oct 2004 06:24:47 -0400 (EDT) From: Robert Watson <rwatson@FreeBSD.org> To: Marc UBM Bocklet <ubm@u-boot-man.de> Subject: Re: [BETA7-panic] sodealloc(): so_count 1 Message-ID: <Pine.NEB.3.96L.1041015062126.84384k-100000@fledge.watson.org> Resent-Message-ID: <Pine.NEB.3.96L.1041015062613.84384l@fledge.watson.org> In-Reply-To: <20041015113321.126a6c4d.ubm@u-boot-man.de>
next in thread | previous in thread | raw e-mail | index | archive | help
On Fri, 15 Oct 2004, Marc UBM Bocklet wrote: > > Sounds good. I know that the problem Brian identified is a real race > > and a potential source of precisely the panic you were seeing. One > > reason I was interested in getting access to a dump from the panic, > > though, was to(if possible) confirm that it was *the* race causing the > > problem. It's a very likely candidate, but it would be good to know > > if we should be looking for another related race. If the code now in > > HEAD fixes it for you, please let me know (or if not, also :-). If it > > doesn't, the core would be very helpful. > > Ok, bad news first: > > I just got exactly the same panic with Brian's > tcp_accept_race_crash.patch applied. > > Debug output is attached, but it looks just like the last time. > > The good news: > > I got a coredump that I can poke. :-) > > So now I just need to know what info to extract from the dump :-) It would be interesting to have you try with the current head of RELENG_5, which now includes my fix, which is a little different from Brian's fix in the sense that it tries to rewrite things less (since that code is very sensitive to change). Regarding the dump -- wonderful. Here's what I'd like you to do. In one of the sofree/sodealloc frames, I'd like to see the contents of *so, to see what state the socket is in. If you move up a few frames to in_pcbdetach(), the contents of *inp would be very useful, and up another frame or so to the tcp_close() frame, *tp. I don't know how fmiliar you are with our kernel debugging suite, but if you're not the documentation in the handbook is fairly decent. The one caveat I'd give is that that documentation might still reference "gdb -k" instead of "kgdb" to work with the core dump. Thanks for your help on this one -- I'm still unable to reproduce the problem in my testbeds, so having someone who's willing to keep following through on the bug is really invaluable! Thanks, Robert N M Watson FreeBSD Core Team, TrustedBSD Projects robert@fledge.watson.org Principal Research Scientist, McAfee Research
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?Pine.NEB.3.96L.1041015062126.84384k-100000>