Project

General

Profile

Actions

Bug #1840

closed

mbufuntrack: mbuf was not tracked

Added by ftigeot over 14 years ago. Updated about 14 years ago.

Status:
Closed
Priority:
Normal
Assignee:
-
Category:
-
Target version:
-
Start date:
Due date:
% Done:

0%

Estimated time:

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/

Actions #1

Updated by peter over 14 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

Actions #2

Updated by dillon over 14 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
<>
Actions #3

Updated by ftigeot over 14 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 :)

Actions #4

Updated by peter over 14 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

Actions #5

Updated by ftigeot over 14 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.

Actions #6

Updated by pavalos about 14 years ago

This is fixed for me. How about you?

Actions #7

Updated by ftigeot about 14 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.

Actions

Also available in: Atom PDF