Thanks I was seeing this myself but had not chased it down.
I've been wondering if we need access to some of the global locks i.e
the window manager
in the gtk port ? My opinion right now is no DirectFB should do the right thing.
Mike
On 12/1/05, Ryan Burns <[EMAIL PROTECTED]> wrote:
> 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
>
_______________________________________________
directfb-dev mailing list
[email protected]
http://mail.directfb.org/cgi-bin/mailman/listinfo/directfb-dev
