On Wed, Nov 30, 2005 at 04:09:30PM -0800, Ryan Burns wrote:
> 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.
The surface manager is already locked in dfb_gfxcard_state_acquire() but
it is also released after the surfaces are locked. You could just change
it release the lock in dfb_gfxcard_state_release(). However holding
the lock across the accel operation(s) may not be a good idea.
I think ideally we should check if the surface is locked before resizing
it. But there is no skirmish used in the surface locking just reference
counts for the buffers. And if we add a skirmish to the surface only one
one user could lock the surface. That doesn't sound like a good idea so
it could really use a rwlock type of thing.
dfb_surface_{hard,soft}ware_lock() should use the read lock and
dfb_surface_reformat() should use the write lock. There is also the
problem of misbehaving applications that could keep the surface Lock()ed
indefinitely.
--
Ville Syrjälä
[EMAIL PROTECTED]
http://www.sci.fi/~syrjala/
_______________________________________________
directfb-dev mailing list
[email protected]
http://mail.directfb.org/cgi-bin/mailman/listinfo/directfb-dev
