the SIGTRAP is a result of the ASSERT. This is not a 'deadly' assert, it signals there is something wrong with the internal locking counter. Since it doesn't reach the counter check, something seems to be wrong with the lock itself. Having code without locking safety will of course work only about 9 times out of a 10 :)
What do you mean with 'terminate normally and get past this statement'? To me 'terminate' is the opposite of 'get past the statement'.. Also, core->shared will be different in memory addresses, obviously, so I need you to specify a bit more if you have spotted significant differences. You may want to try "fatal-level=none" in your directfbrc, to skip asserts and check for similarities in GTK/nonGTK cases. hth Niels eccamacho wrote: > I've compiled DirectFB to mips on a Broadcom box. I'm encountering a weird > situation where I'm getting a SIGTRAP in wm.c. > > (-) [Main Thread 30.487] (19949) Core/WM: dfb_wm_init_stack( > 0x44e888 ) > (!) [Main Thread 30.487] (19949) *** Assertion > [fusion_skirmish_lock_count( &stack->context->lock, &lock_count ) == DR_OK] > failed *** [wm.c:540 in dfb_wm_init_stack()] > (-) [Main Thread 30.487] (19949) - - : Direct/Assertion: > Raising SIGTRAP... > > When I run the directfb tests (dfbtest_window), I can terminate normally and > get past this statement. In GTK programs, I crash here. > > I'm noticing differences in objects such as core->shared when I go through > dfb_core_create between GTK programs and the DFB test programs, but I don't > understand how they are initialized differently. > > Anyone encountered this or have any ideas? > > -- .------------------------------------------. | DirectFB - Hardware accelerated graphics | | http://www.directfb.org/ | "------------------------------------------" _______________________________________________ directfb-dev mailing list directfb-dev@directfb.org http://mail.directfb.org/cgi-bin/mailman/listinfo/directfb-dev
