[ Thread Index |
Date Index
| More lists.liballeg.org/allegro-developers Archives
]
On Wed, 6 Dec 2000, Grzegorz Adam Hankiewicz wrote:
> I still can, but I am suspicious about my own patches, so I will check
> against a clean cvs version soon...
Hmmm... I tried the clean version, deleting all files and downloading
again. The result is a little bit different (and I am starting to think
it's some problem related with the weather, the moon's phases, etc...).
I have tried to compile grabber manually with the following base
commandline 'gcc -o grabber -g grabber.c plugins/*.c datedit.c xxx' from
the allegro/tools directory, creating first a symbolic link to
allegro/obj.
I changed xxx to the following:
1) `allegro-config --static release`
2) `allegro-config --static debug`
3) `allegro-config --shared debug`
4) `allegro-config --shared release`
And after each compilation I run "./grabber -32 ../demo/demo.dat" with the
following results:
1) works
2) works
3) works
4) crash
What I am doing to crash is just press the arrow down key to visualize the
first 60x60 rle sprite. I can see for a moment the text "RLE sprite
(60x60, 8 bit)" and the black box being drawn, but it crashes at that
point, possibly trying to display the rle sprite. If instead of pressing
the arrow key, I press the page down key to select the sample, everything
is allright, until I select an rle sprite again. This seems to happen only
with bmp and rle sprites; fonts, midis, samples and palettes work ok.
This bug is not related with the gfx_safe patch I recently posted, because
it also happens for me under X. For fbcon I get the following gdb
backtrace:
#0 0x8069ae8 in _stub_bank_switch ()
#1 0x40036120 in _al_realloc () from /usr/local/lib/liballeg-3.9.34.so
#2 0xaa in ?? ()
Under X I get this:
#0 0x400a2545 in _xwin_write_line () from /usr/local/lib/liballeg-3.9.34.so
#1 0x400c8e48 in _x_magic_screen_width () from /usr/local/lib/liballeg-3.9.34.so
#2 0x1e0 in ?? ()
Why didn't I see this before? Well, possibly because running grabber under
X and fbcon before always used color depth 8, and know with the gfx_safe
patch grabber uses 32bpp by default (at least under my fbcon, hehe :)
Ok, does this happen to somebody else? I think I will try to revert to
some older cvs version and try again. If this produces the same problem,
then it's possibly a problem with my linux box, maybe having wrong kernel
headers or whatever :-?
Anyway, I am going to keep working on the gfx_safe patch, and will come to
this when I am done, since I can't get the crash working with anything
else than the shared release library, which doesn't help to debug it.
PD: Any suggestions welcome.
Grzegorz Adam Hankiewicz gradha@xxxxxxxxxx - http://gradha.infierno.org
Other web pages: http://glub.ehu.es/ - http://welcome.to/gogosoftware/