Re: mutex fault

[Andrew Doran <ad%netbsd.org@localhost>]

On Mon, Nov 26, 2007 at 08:24:45PM +0900, Kazushi Marukawa wrote:

> Thanks for checking codes.  As you requested, I ran the new
> kernel after compiling with -g option (call it netbsd1122g)
> and got crash trase of it.  Unfortunately, it seems the
> same.  The address is also the same, callout_softclock+0x24d.
> 
> Disasseble of callout_softclock shows following (0x24d=589):
> 
>   0xc043151a <callout_softclock+586>:     call   *0xffffffec(%ebp)
>   0xc043151d <callout_softclock+589>:     movl   $0xc098d594,(%esp)
>   0xc0431524 <callout_softclock+596>:     call   0xc04db580 <mutex_spin_enter>
> 
> Line numbers are:
>   callout_softclock+586: kern/kern_timeout.c 604
>   callout_softclock+589: kern/kern_timeout.c 605
>   callout_softclock+596: kern/kern_timeout.c 605
> 
> And here is the source code.
>   602                                     KERNEL_UNLOCK_ONE(curlwp);
>   603                             } else
>   604                                             (*func)(arg);
>   605                             mutex_spin_enter(&callout_lock);
>   606
>   607                             /*
>   608                              * We can't touch 'c' here because it might 
> be
>   609                              * freed already.  If LWPs waiting for 
> callout
> 
>    > it seems it called mutex_spin_enter instead
>    > of mutex_spin_exit.
> 
> The return address points the address where the program goes
> back, so it points the next address of what it was executing
> in the previous stack frame.
> 
> So, I guess "func" has a pointer to the mutex_vector_exit
> function.  And kernel called it at line 604 above.  Then,
> the kernel crashed inside the function pointed by "func
> (=mutex_vector_exit())".

Is is probably a tail call generated by the compiler. For example:

myfunc(void)
{

        mutex_enter(&foo);
        /* do stuff */
        mutex_exit(&foo);
        return;
}

The last call can be turned into "jmp mutex_exit" by the compiler. Can you
try compiling the kernel with -O0? It will not make those optimizations.

Thanks,
Andrew