Bug #1840

mbufuntrack: mbuf was not tracked

Added by ftigeot over 3 years ago. Updated over 3 years ago.

Status:ClosedStart date:
Priority:NormalDue date:
Assignee:-% Done:

0%

Category:-
Target version:-

Description

This panic occured during the boot sequence with the latest kernel
(v2.7.3.976.gac8b3-DEVELOPMENT). It seems there was severe memory
corruption: symbols in the backtrace were not readable function names
but random ASCII characters.

Crash files are named *.32* and are available at this url:
http://www.wolfpond.org/crash.dfly/

History

#1 Updated by peter over 3 years ago

On Thu, Sep 16, 2010 at 09:17:15AM +0200, Francois Tigeot wrote:
> This panic occured during the boot sequence with the latest kernel
> (v2.7.3.976.gac8b3-DEVELOPMENT). It seems there was severe memory
> corruption: symbols in the backtrace were not readable function names
> but random ASCII characters.
>

I'm having the same thing. Hopefully Matt comes up with a fix soon.

--Peter

#2 Updated by dillon over 3 years ago

:
:This panic occured during the boot sequence with the latest kernel
:(v2.7.3.976.gac8b3-DEVELOPMENT). It seems there was severe memory
:corruption: symbols in the backtrace were not readable function names
:but random ASCII characters.
:
:Crash files are named *.32* and are available at this url:
:http://www.wolfpond.org/crash.dfly/
:
:--
:Francois Tigeot

I spent the last two days working Peter Avalos's machine which
(when we turned on mbuf debugging) was having the same issue.

I think I finally cracked it, and pushed the fix to the udp6 code.
It took a long time to find the bug.

-Matt
Matthew Dillon
<>

#3 Updated by ftigeot over 3 years ago

On Thu, Sep 16, 2010 at 12:42:53AM -0700, Matthew Dillon wrote:
> :
> :This panic occured during the boot sequence with the latest kernel
> :(v2.7.3.976.gac8b3-DEVELOPMENT). It seems there was severe memory
> :corruption: symbols in the backtrace were not readable function names
> :but random ASCII characters.
>
> I spent the last two days working Peter Avalos's machine which
> (when we turned on mbuf debugging) was having the same issue.
>
> I think I finally cracked it, and pushed the fix to the udp6 code.
> It took a long time to find the bug.

The first nameserver entry in resolv.conf was an inet6 address, which is
consistent with the early crash.

Anyway, I confirm it doesn't crash anymore on my machine. Thanks :)

#4 Updated by peter over 3 years ago

On Thu, Sep 16, 2010 at 11:37:11AM +0200, Francois Tigeot wrote:
>
> Anyway, I confirm it doesn't crash anymore on my machine. Thanks :)
>

Let it run for a bit...I'm seeing strange behavior after about an hour.

--Peter

#5 Updated by ftigeot over 3 years ago

On Thu, Sep 16, 2010 at 09:42:07AM +0000, Peter Avalos (via DragonFly issue tracker) wrote:
>
> Peter Avalos <> added the comment:
>
> On Thu, Sep 16, 2010 at 11:37:11AM +0200, Francois Tigeot wrote:
> >
> > Anyway, I confirm it doesn't crash anymore on my machine. Thanks :)
>
> Let it run for a bit...I'm seeing strange behavior after about an hour.

Do you have any example ?

I have seen strange things ever since I upgraded to 2.7.

After some time, keyboard leds don't change state under Xorg for example.
Web sites on slow hosts / different continents have a tendency to not load
completely the first time; the browser tab/window just spins with 100% CPU
and never timeouts.

But these are not specific to this last mbuf issue.

#6 Updated by pavalos over 3 years ago

This is fixed for me. How about you?

#7 Updated by ftigeot over 3 years ago

On Fri, Sep 24, 2010 at 12:47:57AM +0000, Peter Avalos (via DragonFly issue tracker) wrote:
>
> Peter Avalos <> added the comment:
>
> This is fixed for me. How about you?

Same thing here. I think this one can be closed.

Also available in: Atom PDF