Re: [AD] x color conversion again (w/ responsiveness patch)

[ Thread Index | Date Index | More lists.liballeg.org/allegro-developers Archives ]


On Mon, 2004-07-19 at 23:32 +0200, Evert Glebbeek wrote:
> On Monday 19 July 2004 18:19, Evert Glebbeek wrote:
> > WIP 4.1.11 works.
> > I'll see if I can investigate later tonight.
> 
> I can reproduce the crash with the test program when repeatedly switching 
> modes, but apparently only when the colour depth is different from the 
> desktop colourdepth and never the first time a mode switch is made.

I'll try doing the same with the signals version.. the different color-
depth can mean 2 things: It's yet another problem with color conversion,
or it's a race condition, and since the color conversion makes us spend
a lot of time in the color converters, it only occurs with it - but
doesn't really tell us anything else.

> The demo program runs normally if I remove the call to gfx_mode_select(), 
> so I suspect the problem is related to that.
> As I said, I have no problems with WIP 4.1.11 and earlier (I checked 4.0.3 
> and 4.1.3), but I get crashes with 4.1.12 and later (4.14, CVS).
> 
> I went through the changelog from 4.1.11 to 4.1.12 and the diff itself and 
> couldn't really find anything that I'd expect to cause a crash.
> 

Hm, that's bad. It wouldn't necessarily have to be a change to the X11
or unix port itself - maybe just some general change which triggers the
error under X11.

> Am I really the only one getting these crashes?
> 

While hunting down the asm color converters bug, the test program once
showed an X11 error right at startup. So, the problem is also here I
think - but very rare. From what you said, it sounds there's a bug when
changing the gfx mode.

With the threaded version we have XLOCK/XUNLOCK to guard against X11
race conditions. In the signals version, XLOCK/XUNLOCK basically turn
away to nothing (they only block the background handler with a variable)
- so we are likely having a problem at that point. Maybe a simple
variable isn't enough to guard the background handler? A signal can
happen between any two asm instructions after all. Could be something
entirely else though - I was a long time on the wrong track with the
color converters as well (even though my initial guess turned out to be
right in the end).

-- 
Elias Pschernig





Mail converted by MHonArc 2.6.19+ http://listengine.tuxfamily.org/