On 26-Jul-2002 andrew bliznak wrote:
> John Baldwin wrote:
>> On 26-Jul-2002 andrew bliznak wrote:
>> 
>>>#14 0xc03179d8 in calltrap () at {standard input}:98
>>>#15 0xc01e4db5 in _mtx_lock_sleep (m=0x28, opts=0, file=0x0, line=0)
>>>     at /usr/home/andrew/C/src/sys/kern/kern_mutex.c:598
>> 
>> 
>> This is the bug, it's like it is dereferencing a null pointer to get
>> a mutex or something.
>> 
>> 
>>>#16 0xc026f71d in tcp_input (m=0xc0f10100, off0=20)
>>>     at /usr/home/andrew/C/src/sys/netinet/tcp_input.c:520
>> 
>> 
>>         /*
>>          * Locate pcb for segment.
>>          */
>>          INP_INFO_WLOCK(&tcbinfo);
>>          headlocked = 1;
>> 
>> #define INP_INFO_WLOCK(ipi)     mtx_lock(&(ipi)->ipi_mtx)
>> 
>> I don't see why it should be a problem though, tcbinfo is a global
>> var.
> 
> Hm, little more debuging, m in sys/kern/kern_mutex.c:595 is wrong!

It's wrong on the stack.  Look at the _mtx_lock_sleep() line above.
I would say print the value of m in gdb, but gdb doesn't always get
local variables right (maybe the new gcc and dwarf stuff isn't subject
to that).

Actually, I think gdb has screwed up your backtrace some anyway.  Back
to the original fault messages:

fault virtual address   = 0x24
fault code              = supervisor read, page not present
instruction pointer     = 0x8:0xc01e4b02

Can you do 'l *0xc01e4b02' in gdb and show the output?

-- 

John Baldwin <[EMAIL PROTECTED]>  <><  http://www.FreeBSD.org/~jhb/
"Power Users Use the Power to Serve!"  -  http://www.FreeBSD.org/

To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message

Reply via email to