Re: panic when invoking recvfrom
Re: panic when invoking recvfrom
- Subject: Re: panic when invoking recvfrom
- From: Mark Rhoads <email@hidden>
- Date: Thu, 26 Jul 2007 11:49:04 -0700
- Organization: WiredRoads
Hello Peter,
The most interesting part of these backtraces, to me at least, is the
"freeing free mbuf" panic message in the first backtrace, and that the
second backtrace, if it is indeed a panic, has 'stopped' in a different
location:
#0 Debugger (message=0x30d3e4 "panic")
at /SourceCache/xnu/xnu-792.21.3/osfmk/ppc/model_dep.c:639
#1 0x00026898 in panic (str=0x32d19c "freeing free mbuf")
at /SourceCache/xnu/xnu-792.21.3/osfmk/kern/debug.c:202
#2 0x0028cb60 in m_free (m=0x280df900)
at /SourceCache/xnu/xnu-792.21.3/bsd/kern/uipc_mbuf.c:600
...
#0 0x000aca3c in forward32bit ()
#1 0x000ab418 in copyin3 ()
#2 0x00273820 in uiomove64 (cp=0, n=16225, uio=0x1d9ed80)
at /SourceCache/xnu/xnu-792.21.3/bsd/kern/kern_subr.c:164
While both appear within recvfrom(), you might consider that this may be
a memory related problem that is caused by something else: another
system call or ?? E.g. a "freeing free mbuf" panic notice could be
exactly as it declares, or it could be the result of some other kernel
memory structure becoming corrupted. I would doubt that after all this
time that a 'straightforward' "freeing free mbuf" would be the direct
cause instead of a symptom of something else that has gone wrong,
particularly since the two backtraces appear to be different. Merely
reviewing the backtraces probably will not result in a diagnosis. A
full copy of the resulting panic core (submit as a bug report to ADC,
not to me) would be of more help, and can get the ball rolling at ADC
while you try to build a test case, but still not guaranteed. Building
a test case to demonstrate the problem is much more likely to result in
a diagnosis. But, in this case, building a 'simple' test case to
reproduce the problem may not be so simple.
You might try investigating your application to try to determine just
what it is about your application that is causing the problem. Consider
that the data itself can be a source of the problem. Check the data
sizes that are sent/received (and data structures and parameters to all
system calls), try changing the timing, etc. You might even want to use
a packet sniffer to examine the packets on the wire -- you might find a
better correlation between the panic and network events/data/timing (I
would try this first, since it is fairly easy to do). Finally, instead
of trying to build a test case up from scratch, try transforming your
application into a test case. Remove UI's, use dummy data, etc. You
might also try to replace the recvfrom's in your application with a
'dummy' routine and data that would still allow your application to
continue running. If you still get panics or crashes, then you know
that the problem is not directly due to recvfrom and can focus more upon
other aspects of your application.
--Mark Rhoads
_______________________________________________
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