Hiya Ed.
I can tell you what I see, not sure if it will be helpful.
First, your shared contains a Union, so the two different values are in
fact one.
the 'owner' is only used for multi-app without fusion kernel module, not
supported in 1.2.x (which I think is what you are using) and will
contain a tid, normally a large number.
So it looks like you are using single app, so the difference is __m_kind
which is a parameter of pthread_mutex_t. From what I can see this means
that the attribute has been changed by settype to
PTHREAD_MUTEX_RECURSIVE, which I cannot find in DirectFB, so you might
check your GTK sources if it happens there; that would be a reasonably
logical explanation anyway, if GTK contains recursion in DirectFB calls.
Still a bit iffy..
hth
Niels
Ed Camacho wrote:
> 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 <[email protected]
> <mailto:[email protected]>> 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 - Hardware accelerated graphics |
| http://www.directfb.org/ |
"------------------------------------------"
_______________________________________________
directfb-dev mailing list
[email protected]
http://mail.directfb.org/cgi-bin/mailman/listinfo/directfb-dev
