Thanks for the feedback.
I wasn't aware the core surface code was being changed. I'll look into your
suggestion today or tomorrow as a work around and submit a new patch.
--
Ryan Burns <[EMAIL PROTECTED]>
MontaVista Software, Inc.
On Thu, 1 Dec 2005 20:09:46 +0100
Denis Oliver Kropp <[EMAIL PROTECTED]> wrote:
> 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
