Bug #1840
mbufuntrack: mbuf was not tracked
| Status: | Closed | Start date: | ||
|---|---|---|---|---|
| Priority: | Normal | Due 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/
Related todos
History
Updated by peter over 2 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
Updated by dillon over 2 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
<dillon@backplane.com>
Updated by ftigeot over 2 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 :)
Updated by peter over 2 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
Updated by ftigeot over 2 years ago
On Thu, Sep 16, 2010 at 09:42:07AM +0000, Peter Avalos (via DragonFly issue tracker) wrote:
>
> Peter Avalos <peter@theshell.com> 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.
Updated by pavalos over 2 years ago
This is fixed for me. How about you?
Updated by ftigeot over 2 years ago
On Fri, Sep 24, 2010 at 12:47:57AM +0000, Peter Avalos (via DragonFly issue tracker) wrote:
>
> Peter Avalos <pavalos@theshell.com> added the comment:
>
> This is fixed for me. How about you?
Same thing here. I think this one can be closed.