Re: Debugging Proprietary KEXTs
Re: Debugging Proprietary KEXTs
- Subject: Re: Debugging Proprietary KEXTs
- From: Andrew Gallatin <email@hidden>
- Date: Sun, 4 Feb 2007 09:49:36 -0500 (EST)
R. Tyler Ballance writes:
> panic(cpu 0 caller 0x0035BEAC): freeing free mbuf
<....>
> The crash obviously looks like it's coming from the Yukon driver for
> my Gigabit adapter, but the question I'm trying to figure out the
> answer to, is if it's parallels (which, painfully, I need for my day
> job) or if it's a bug in Apple's driver. I say parallels, because
This can easily be anybody's fault, unfortunately. I had a bug in one
of the ethernet drivers that I wrote which resulted in the exact same
panic, often without my driver listed on the stack.
My particular bug was that I called a function (mbuf_pullup()) which I
stupidly did not realize would free an mbuf and hand my a replacement.
The result was that I continued to reference the original, now free,
mbuf. Another context would come along and allocate that free mbuf
and some time later I would free the mbuf. The other context would
then free the mbuf, triggering the "freeing free mbuf" panic.
I don't have parallels myself. Is it possible to disable all their
networking support and see if the panic goes away? I'm not sure what
sort of debugging technique you could use to prove that this is
parallels' fault without having the source. I finally found my bug by
inspection. Hmm.. If you have 10.5, and parallels' works on 10.5, you
*might* be able to use dtrace to track all mbuf allocations and frees.
Good luck!
Drew
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Darwin-kernel mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden