Okay so I was existing if exec failed :)
But in
idirectfbinputbuffer.c the pipes should be close on exec.
diff --git a/src/input/idirectfbinputbuffer.c b/src/input/idirectfbinputbuffer.c
index 22adf34..66fb2e4 100644
--- a/src/input/idirectfbinputbuffer.c
+++ b/src/input/idirectfbinputbuffer.c
@@ -31,6 +31,8 @@
#include <stdio.h>
#include <stdlib.h>
#include <unistd.h>
+#include <fcntl.h>
+
#include <string.h>
#include <errno.h>
@@ -511,6 +513,9 @@ IDirectFBEventBuffer_CreateFileDescriptor(
IDirectFBEventBuffer *thiz,
pthread_mutex_unlock( &data->events_mutex );
return errno2result( errno );
}
+ fcntl (data->pipe_fds[0], F_SETFD, FD_CLOEXEC);
+ fcntl (data->pipe_fds[1], F_SETFD, FD_CLOEXEC);
+
/* Enter pipe mode. */
data->pipe = true;
On Dec 31, 2007 8:59 PM, Mike Emmel <[EMAIL PROTECTED]> wrote:
> 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
directfb-dev@directfb.org
http://mail.directfb.org/cgi-bin/mailman/listinfo/directfb-dev
