More info I'm getting this in the X11 backend with the simple fork
call finally got a debuggable crash.
(gdb) bt
#0 0xffffe410 in __kernel_vsyscall ()
#1 0xb7f1691b in ?? () from /lib/i686/cmov/libpthread.so.0
#2 0xb7c2b73e in ?? () from /usr/lib/libX11.so.6
#3 0x0000000a in ?? ()
#4 0x080d2620 in ?? ()
#5 0x00000004 in ?? ()
#6 0xb56fdd31 in localUnlock (pool=0x80c8920, pool_data=0x80d2620,
pool_local=0x4, allocation=0xb5733bac, alloc_data=0x822d110,
lock=0xb56fdd20)
at local_surface_pool.c:247
#7 0xb7c2b29f in _X11TransWrite () from /usr/lib/libX11.so.6
#8 0xb7c30bd6 in ?? () from /usr/lib/libX11.so.6
#9 0x080c8920 in ?? ()
#10 0x080d2620 in ?? ()
#11 0x00000004 in ?? ()
#12 0xb7c19c9d in ?? () from /usr/lib/libX11.so.6
#13 0x0822d110 in ?? ()
#14 0x080e1a98 in ?? ()
#15 0xb7f11531 in pthread_mutex_lock () from /lib/i686/cmov/libpthread.so.0
#16 0xb7c30cab in _XReply () from /usr/lib/libX11.so.6
#17 0xb7c280b8 in XSync () from /usr/lib/libX11.so.6
#18 0xb562c55c in update_screen (surface=<value optimized out>, x=0,
y=135079456, w=800, h=600, lock=0x80d0624) at primary.c:412
#19 0xb562c633 in dfb_x11_update_screen_handler (data=0x80c9720) at
primary.c:456
#20 0xb562d036 in call_handler (caller=1, call_arg=1, call_ptr=0x4,
ctx=0x0, serial=0, ret_val=0xbfdcd768) at x11.c:365
#21 0xb6347e48 in fusion_call_execute (call=0x80c97d8,
flags=FCEF_NONE, call_arg=1, call_ptr=0x80c9720, ret_val=0xbfdcd7a8)
at call.c:514
#22 0xb562c0c5 in dfb_x11_update_screen (region=0xbfdcd7d4,
lock=0x80d0624) at primary.c:96
#23 0xb562c376 in primaryFlipRegion (layer=0x80c87b8, driver_data=0x0,
layer_data=0x0, region_data=0x0, surface=0x80cfcd8, flags=DSFLIP_NONE,
lock=0x80d0624) at primary.c:333
#24 0xb56faffa in dfb_layer_region_flip_update (region=0x80d04e8,
update=0xbfdcd87c, flags=<value optimized out>) at layer_region.c:512
---Type <return> to continue, or q <return> to quit---
So I think we now have a problem with the new surface pools and forking ?
It does not look like a X11 problem.
On Dec 31, 2007 8:36 PM, Mike Emmel <[EMAIL PROTECTED]> wrote:
> Maybe I should mention why I'm looking at directfb some more.
>
> If I do this.
>
> pid_t pID;
>
> pID=fork();
> if( pID == 0 ) {
> exit(0);
> }
>
> I get this.
>
> (!!!) *** WARNING [Application exited without deinitialization of
> DirectFB!] *** [core.c:858 in dfb_core_deinit_check()]
> (!!!) *** WARNING [still objects in 'Layer Region Pool'] ***
> [object.c:241 in fusion_object_pool_destroy()]
> (!!!) *** WARNING [still objects in 'Layer Context Pool'] ***
> [object.c:241 in fusion_object_pool_destroy()]
> (!!!) *** WARNING [still objects in 'Surface Pool'] ***
> [object.c:241 in fusion_object_pool_destroy()]
>
>
>
>
> On Dec 31, 2007 8:27 PM, Mike Emmel <[EMAIL PROTECTED]> wrote:
> > I'm running into some fascinating problems related to forking.
> >
> > I found this.
> >
> > pthread_atfork
> >
> > In my particular case I'm having some problems with the X11 demo back
> > end related to
> > XShm getting munged after a fork.
> >
> > But I'm not clear on whats going on but since DirectFB is multi
> > threads we may need to consider
> > if a few more pthreads_atforks are needed.
> >
> > I noticed the calls in fusion.c but what about XShm for the X11 backend ?
> >
> > Googling did not reveal if something needs to be done. I did not find
> > any use of pthread_atfork in the X11 server either.
> >
> >
> >
> > Mike
> >
>
_______________________________________________
directfb-dev mailing list
[email protected]
http://mail.directfb.org/cgi-bin/mailman/listinfo/directfb-dev
