Martin Husemann wrote:
> On Sat, Feb 24, 2007 at 06:13:10AM +1100, matthew green wrote:
>   
>> from this 'ok' prompt type 'ctrace' - it will give you the stack
>> trace, including the offending pc...
>>     
>
> Also, please check which of the following options you can add without
> the problem going away: LOCKDEBUG, DEBUG, DIAGNOSTIC.
>
> There are three new assembler routines, two of which are not used if
> LOCKDEBUG is enabled. DEBUG adds some window handling changes, which could
> hide bugs, and also DEBUG and DIAGNOSTIC (to different degrees) modify
> the timing, which could affect race conditions.
>
> One of my regular test machines is broken right now (disk to be replaced
> on monday), the other one seems to work fine (it has just done a native
> build.sh) - but maybe I'm lucky, or using some magic combination of options
> that hides the bug.
>
>
> Martin
>   

Here's what I've pieced together from what the firmware spits out after SIR

ctx_free+0x0  (save  %sp, -192, %sp)
  causes a trap. We eventually end up in
kdb_trap+0x268 (ldsw  [ %g2 + 0x58 ], %o1)
  here we take another trap, leading to
winfault+0x38 ( sir )

Is ctx_free() is somehow called on an invalid stack?

-Tobias