Niels,
After directfb.c:193, the core_dfb looks like this in a GTK program:
(gdb) print *core_dfb->shared
$2 = {magic = 641074236, lock = {multi = {id = 0, shared = 0x0, builtin = {
locked = 0, *owner = 0*, waiting = 0x0, requested = false,
destroyed = false}}, single = {lock = {__m_reserved = 0,
__m_count = 0, __m_owner = 0x0, *__m_kind = 0*, __m_lock = {
__status = 0, __spinlock = 0}}, cond = {__c_lock = {__status = 0,
__spinlock = 0}, __c_waiting = 0x0}, count = 0}}, active = false,
layer_context_pool = 0x44a658, layer_region_pool = 0x44a6c0,
palette_pool = 0x44a740, surface_pool = 0x44a7c0, window_pool = 0x44a840,
shmpool = 0x445330, shmpool_data = 0x44a600}
In the dfbtest_window test program, at the same point:
(gdb) print *core_dfb->shared
$1 = {magic = 641074236, lock = {multi = {id = 0, shared = 0x0, builtin = {
locked = 0,* owner = 1*, waiting = 0x0, requested = false,
destroyed = false}}, single = {lock = {__m_reserved = 0,
__m_count = 0, __m_owner = 0x0, *__m_kind = 1*, __m_lock = {
__status = 0, __spinlock = 0}}, cond = {__c_lock = {__status = 0,
__spinlock = 0}, __c_waiting = 0x0}, count = 0}}, active = false,
layer_context_pool = 0x448988, layer_region_pool = 0x4497d0,
palette_pool = 0x449838, surface_pool = 0x4498a0, window_pool = 0x449908,
shmpool = 0x449720, shmpool_data = 0x448930}
What do the differences in owner and kind represent? At this point in the
programs, I don't see why they would differ. Stack traces up to this point
are identical. I admit I don't understand the architect behind this system
yet so spotting differences in data structures is largely the only way I can
debug right now.
On Wed, Feb 11, 2009 at 2:23 AM, Niels Roest <ni...@directfb.org> wrote:
> 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
