| Re: [AD] x color conversion again |
[ Thread Index |
Date Index
| More lists.liballeg.org/allegro-developers Archives
]
On Wed, 2004-07-14 at 09:58 +0200, Evert Glebbeek wrote:
> Elias said:
> > Hm, odd. Are you sure you have no parts of one of the input handler
> > patches still included?
>
> Yes; I just retried with a clean CVS (which did include the colour
> conversion patch). It's strange, but I don't get crashes from anything
> other than the demo program.
> I think the stack traceback iscorrupted though:
> #0 0x40248822 in select () from /lib/i686/libc.so.6
> #1 0x4016da88 in __JCR_LIST__ () from /usr/X11R6/lib/libX11.so.6
> #2 0x00000008 in ?? ()
> #3 0xbfffe720 in ?? ()
> #4 0x400a9085 in _XWaitForWritable () from /usr/X11R6/lib/libX11.so.6
> #5 0x400a96fa in _XFlushInt () from /usr/X11R6/lib/libX11.so.6
> #6 0x400a9679 in _XFlush () from /usr/X11R6/lib/libX11.so.6
> #7 0x400a5fa8 in XSync () from /usr/X11R6/lib/libX11.so.6
> #8 0x080a4f5a in _xwin_set_palette_range ()
> #9 0x08101070 in ?? ()
>
Yes, in my case, the backtrace also starts with ??, so something gets
corrupted here :| And in my case, I get it with any 8-bit program, so
almost all the examples.
> I also sometimes get
> X Error of failed request: BadPixmap (invalid Pixmap parameter)
> Major opcode of failed request: 0 ()
> Resource id in failed request: 0x800
> Serial number of failed request: 16288
> Current serial number in output stream: 881
> Xlib: sequence lost (0x10000 > 0x376) in reply type 0x1f!
> X Error of failed request: BadPixmap (invalid Pixmap parameter)
> Major opcode of failed request: 0 ()
> Resource id in failed request: 0x800
> Serial number of failed request: 16288
> Current serial number in output stream: 886
>
> Program exited with code 01.
>
> which is Xlib shutting down properly, but not very helpful. I just noticed
> something peculiar in the gdb output though:
> (gdb) r
> Starting program: /home/allegro/Allegro/cvs/mainline/alleg_work/demo/demo
> (no debugging symbols found)...(no debugging symbols found)...
> (no debugging symbols found)...(no debugging symbols found)...
> (no debugging symbols found)...(no debugging symbols found)...
> (no debugging symbols found)...[New Thread 16384 (LWP 14716)]
>
> I'm using the signal version. Why is it starting a new thread?
>
I think that's the one main thread. Type "info threads", and it will
show all running threads. It should be exactly one for the signals
version.
In any case, this sounds bad. Does the 4.1.14 release work for you with
signals without problems? If so - we broke something. For me, by
reverting xwin.c to 1.56, the signals version works (or alternatively by
applying the patch disabling conversion from 8-bit).
> Chris said:
> > That's odd. Are you sure you don't have Elias's patch still there? It
> > looks like it's trying to call _xwin_private_handle_input (which is
> > static), but my patch calls _xwin_handle_input (which is global and
> > declared right above).
>
> It applies cleanly to CVS, so I guess I had some random patches still
> installed. However, programs I try to run simply hang. Could you send me
> your latest patches again? I may be using an old version.
>
Chris: can you also test the signals version, with a supposed to be
working version, e.g. 4.1.14 release, and latest CVS? If it turns out
4.1.14 is already crashing for some of us - we can stop investigating
this much for now, since the problem could be anywhere.
--
Elias Pschernig