Hello,
I've been working with directfb-0.9.24 with gtk-2.8.3, and just about everytime
I
resize a window using the mouse, the application segfaults. I've looked at the
problem a bit, and it seems to me that there is a race condition between the
input
triggered dfb_surface_reformat (when resizing), and
IDirectFBSurface_FillRectangle
and the functions it calls.
The application usually segfaults in Cop_to_Aop_32 while trying to write to
memory
that was just freed in dfb_surface_reformat:
#0 0xb7f9b010 in Cop_to_Aop_32 (gfxs=0x80a6d98) at
#../../../../src/gfx/generic/generic.c:147 1 0xb7facced in gFillRectangle
#(state=0x1, rect=0xbffffc40) at ../../../../src/gfx/generic/generic.c:7070 2
#0xb7fb4e40 in dfb_gfxcard_fillrectangles (rects=0xbffffc40, num=1,
#state=0x80a7a38) at ../../../src/core/gfxcard.c:713 3 0xb7f82f3c in
#IDirectFBSurface_FillRectangle (thiz=0x80a79e0, x=0, y=0, w=538, h=621) at
#../../../src/display/idirectfbsurface.c:897
...
For this specific instance, I was able to solve my problem by locking the
surface
manager in IDirectFBSurface_FillRectangle becuase thats the same lock that
dfb_surface_reformat uses. I notice in dfb_gfxcard_fillrectangles it locks the
state, but I dont see a way of locking it in dfb_surface_reformat.
I'm not real familiar with the internals of DirectFB yet, so I don't know if
this
is an appropriate solution. If it is, this sort of locking will need to be added
in several places.
Heres what my incomplete patch looks like:
diff -ru DirectFB-0.9.24.clean/src/display/idirectfbsurface.c
DirectFB-0.9.24.fix/src/display/idirectfbsurface.c
--- DirectFB-0.9.24.clean/src/display/idirectfbsurface.c 2005-07-15
06:30:19.000000000 -0700
+++ DirectFB-0.9.24.fix/src/display/idirectfbsurface.c 2005-11-29
10:29:03.000000000 -0800
@@ -873,6 +906,7 @@
IDirectFBSurface_FillRectangle( IDirectFBSurface *thiz,
int x, int y, int w, int h )
{
+ CardState *state;
DFBRectangle rect = { x, y, w, h };
DIRECT_INTERFACE_GET_DATA(IDirectFBSurface)
@@ -890,11 +924,22 @@
if (w<=0 || h<=0)
return DFB_INVARG;
+
+ state = &data->state;
+
+ if(state->source)
+ dfb_surfacemanager_lock((state->source)->manager);
+ dfb_surfacemanager_lock((state->destination)->manager);
+
rect.x += data->area.wanted.x;
rect.y += data->area.wanted.y;
dfb_gfxcard_fillrectangles( &rect, 1, &data->state );
+ if(state->source)
+ dfb_surfacemanager_unlock((state->source)->manager);
+ dfb_surfacemanager_unlock((state->destination)->manager);
+
return DFB_OK;
}
As a simpler alternative, I'm wondering if I can just lock the surface managers
inside dfb_state_lock? In the cases I've looked at so far, it seems that just
about everytime the state is locked the surface is also being used, but I guess
that doesn't always have to be true. Are there any reasons not to do this?
I'd greatly appreciate any comments or suggestions. I'd like to create my patch
so
that I may submit it back to be included in the directfb sources.
Here is the patch:
--- DirectFB-0.9.24.clean/src/core/state.h 2005-02-28 01:40:59.000000000
-0800
+++ DirectFB-0.9.24.fix/src/core/state.h 2005-11-30 13:49:06.000000000
-0800
@@ -40,6 +40,9 @@
#include <core/coretypes.h>
#include <core/gfxcard.h>
+#include <core/surfaces.h>
+#include <core/surfacemanager.h>
+
#include <gfx/generic/generic.h>
#include <misc/util.h>
@@ -141,6 +144,11 @@
DFB_REGION_ASSERT( &state->clip );
+ if(state->source)
+ dfb_surfacemanager_lock((state->source)->manager);
+ if(state->destination)
+ dfb_surfacemanager_lock((state->destination)->manager);
+
pthread_mutex_lock( &state->lock );
}
@@ -151,6 +159,11 @@
DFB_REGION_ASSERT( &state->clip );
+ if(state->source)
+ dfb_surfacemanager_unlock((state->source)->manager);
+ if(state->destination)
+ dfb_surfacemanager_unlock((state->destination)->manager);
+
pthread_mutex_unlock( &state->lock );
}
Thanks,
Ryan Burns
--
Ryan Burns <[EMAIL PROTECTED]>
MontaVista Software, Inc.
_______________________________________________
directfb-dev mailing list
[email protected]
http://mail.directfb.org/cgi-bin/mailman/listinfo/directfb-dev
