It seems that this is the usual enemy of debugging: compiler optimisation.Hmm. Odd. The stack trace in your screen shot shows the same mbuf being passed to icmp_error() was was passed to ip_forward(). This suggests, given the other arguments, that it's actually the call to icmp_error() on line 1650, not 1879. I wonder if addr2line is getting confused.
There's actually only one call. The call in line 1650 jumps to the one generated by line 1879.
(line numbers don't match, because I am runnig 6-Current on this machine)
/usr/src/sys/netinet/ip_input.c:1711 (1650) 103a: 6a 00 push $0x0 103c: 6a 00 push $0x0 103e: 6a 01 push $0x1 1040: 6a 03 push $0x3 1042: 56 push %esi 1043: e9 fa fd ff ff jmp e42 <ip_forward+0x1a6>
/usr/src/sys/netinet/ip_input.c:1711 (1650)
e41: 56 push %esi
/usr/src/sys/netinet/ip_input.c:1940 (1879)
e42: e8 fc ff ff ff call e43 <ip_forward+0x1a7>
e47: eb e8 jmp e31 <ip_forward+0x195>If you use kgdb on the kernel.debug and do:
l *icmp_error+0x191 l *ip_forward+0x3d1
Do you get different answers?
Maybe it would help to compile the kernel with INVARIANTS.
Then we should get a false assertion somewhere earlier and closer to the problem.
I assume that their is an invalid/null mbuf somewhere. It seems that this comes more or less directly from the inferface driver.
Just my two cents...
_______________________________________________ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
