Quoting Ville Syrjälä:
> 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.
Yes, the surface manager shouldn't be locked all the time.
> 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.
For now, it would be enough to wait for all lock counters being zero
in dfb_surface_reformat(). A simple loop that locks/checks(/unlocks)
might be sufficient.
I'm still (actively) working on the new surface core code,
so it wouldn't be worth it to put too much effort into the old code.
--
Best regards,
Denis Oliver Kropp
.------------------------------------------.
| DirectFB - Hardware accelerated graphics |
| http://www.directfb.org/ |
"------------------------------------------"
_______________________________________________
directfb-dev mailing list
[email protected]
http://mail.directfb.org/cgi-bin/mailman/listinfo/directfb-dev
