| Re: [AD] x color conversion again |
[ Thread Index |
Date Index
| More lists.liballeg.org/allegro-developers Archives
]
On Tue, 2004-07-13 at 00:13 +0200, Elias Pschernig wrote:
> Hm, almost forgot, playing around with the signals version I noticed
> that it doesn't work at all with the color conversion patch. I suspect,
> it is missing some XLOCK somewhere or something.
>
Ok, I played around a bit with this, but couldn't find out anything.
With gdb, it always crashes in icolconv.s:
(gdb) r
Starting program: /home/elias/prog/allegro/examples/expal
[Thread debugging using libthread_db enabled]
[New Thread 1076306592 (LWP 10025)]
Program received signal SIGSEGV, Segmentation fault.
[Switching to Thread 1076306592 (LWP 10025)]
next_block_8_to_32 () at src/misc/icolconv.s:306
306 movl (%esi), %edx /* edx = [4][3][2][1] */
Current language: auto; currently asm
(gdb) bt
#0 next_block_8_to_32 () at src/misc/icolconv.s:306
#1 0xbffff980 in ?? ()
#2 0x40270190 in timezone () from /lib/tls/libc.so.6
#3 0x000000d2 in ?? ()
#4 0xbffff448 in ?? ()
#5 0x080816e6 in _xwin_private_fast_colorconv (sx=0, sy=0, sw=0, sh=0)
at src/x/xwin.c:1647
Previous frame inner to this frame (corrupt stack?)
(gdb)
But it seems to be a bogus traceback, the real cause probably being
somewhere else. The sx=0,sy=0,w=0,h=0 for example does never occur
really.
The problem only occurs with 8-bit color depth (I tried all others in
the test program, no crashes there), and with the signals version
(everything works with threads). And, in case it wasn't clear so far,
this is a plain, unmodified CVS version. If I revert xwin.c to 1.56,
everything works again.
My guess is, when a signal arrives at the wrong moment, it messes up the
color conversion.
Is there a way to somehow see more in gdb? Like, if there was a signal
before the crash? I'm a bit lost right now.
--
Elias Pschernig