I was compiling my emulator with Allegro 4.0.3 (stable) with no problems. On recent upgrade to Allegro 4.1.6 WIP, there's a strange error...

Program received signal SIGSEGV, Segmentation fault.
0x67fece63 in clear_bitmap ()
(gdb) q
The program is running.  Exit anyway? (y or n) y

I am using an Allegro GUI. In an easy Quit to OS, it freezes. The GDB shows that message. I don't call clear_bitmap() or clear_to_color() in my code.
Any help?

That is a bug indeed, I think I remember WH suffered it. Let me see if I find the thread...

Make sure you properly installed the new headers. Also make sure to delete and rebuild all object files and libraries using Allegro.

Well, I trust Allegro's makefile firstly... since I did (now) a clean installation of everything, and the problem persists.

I use MinGW. In the makefile, i changed '-mcpu=pentium' to '-march=i686', since '-mcpu' is deprecated.

Except for the headers part, I meant your program. AllegroGL, DUMB, etc.. need to rebuilt those too since they're expecting a different version of Allegro that has different structure sizes.

Needless to say that...
Anyway, I'll trace the Allegro sources to find the clear_bitmap() line call.

Not really helping with your problem, but the replacement for -mcpu is -mtune.

EDIT: Oh, and pentium is deprecated in favour of i586, not i686, so "-mcpu=pentium" should be changed to "-mtune=i586".

Oh, thanks for the info. Anyway, I use i686 because I run on Duron 1.1GHz (non-Intel if matters)...

Is just me with this clear_bitmap() problem?

It sounds like a vtable problem. Everytime I've seen it, it's either due to older headers with a newer lib (or vice versa), stale object files from the project, or libraries that rely on Allegro that haven't been recompiled.

During the compiling, there are a few warning messages, related to deprecated items in Allegro... I use the latest gcc (3.4.2 candidate).

Quite possible. Some of the most common functions, like textprintf, have changed to _ex (like textprintf_ex).

I'm not saying the comiplation of my emulator, but the Allegro source compiling - like the 'timer_retrace_whatever is deprecated'.

Hmm... where? I did not have problems with that (last time I compiled .16 were months ago).

Follows the output:

gcc -DALLEGRO_SRC -Wall -Wno-unused -mtune=i686 -O2 -funroll-loops -ffast-math -fomit-frame-pointer -I. -I./include -o obj/mingw32/alleg/graphics.o -c src/graphics.c
src/graphics.c: In function `set_gfx_mode':
src/graphics.c:659: warning: `timer_simulate_retrace' is deprecated (declared at ./include/allegro/alcompat.h:240)

Here another warning:

gcc -DALLEGRO_SRC -Wall -Wno-unused -mtune=i686 -O2 -funroll-loops -ffast-math -fomit-frame-pointer -I. -I./include -o obj/mingw32/alleg/timer.o -c src/timer.c

src/timer.c: In function `timer_simulate_retrace':
src/timer.c:219: warning: `timer_can_simulate_retrace' is deprecated (declared at src/timer.c:204)

Here one more, about lvalues:

gcc -DALLEGRO_SRC -Wall -Wno-unused -mtune=i686 -O2 -funroll-loops -ffast-math -fomit-frame-pointer -I. -I./include -o obj/mingw32/alleg/wddbmp.o -c src/win/wddbmp.c
src/win/wddbmp.c: In function `make_bitmap_from_surface':
src/win/wddbmp.c:333: warning: use of cast expressions as lvalues is deprecated
src/win/wddbmp.c: In function `gfx_directx_destroy_video_bitmap':
src/win/wddbmp.c:509: warning: use of cast expressions as lvalues is deprecated
src/win/wddbmp.c: In function `flip_with_forefront_bitmap':
src/win/wddbmp.c:565: warning: use of cast expressions as lvalues is deprecated
src/win/wddbmp.c:569: warning: use of cast expressions as lvalues is deprecated

Here:

gcc -DALLEGRO_SRC -Wall -Wno-unused -mtune=i686 -O2 -funroll-loops -ffast-math -fomit-frame-pointer -I. -I./include -o obj/mingw32/alleg/wddwin.o -c src/win/wddwin.c
src/win/wddwin.c: In function `gfx_directx_show_video_bitmap_win':
src/win/wddwin.c:478: warning: use of cast expressions as lvalues is deprecated

The timer retrace ones are fixed in CVS. The cast expression ones come from macros in the DirectX header files so are not our problem.

Did you call "make uninstall" with 4.0.3, and "make install" with the new? Just want to make sure, since as KittyCat said, this problem is normally a version conflict.

I deleted the entire C:\Dev-Cpp directory (MinGW + Allegro), and I did a reinstall from scratch.

Hm. Also remove the alleg*.dll from the windows system folder. And are you sure all the headers are in C:\Dev-Cpp? Some people also have c:\mingw and c:\msys\mingw and so on

Anyway, of course it's possible that there's a bug in clear_bitmap. But it just is quite unlikely, given how many times it is used. Maybe try recompiling, but don't change any optimization flags. It may be connected to that, AJ also reported problems when compiling with /G7 for MSVC.

No C:\mingw directories! ^_^;;
The only one is C:\Dev-Cpp and its subfolders, where Allegro and MinGW are installed.

About the CVS, if this is the package, the graphics.c file is outdated (september), still giving the same warning message.

Well, provide some more info then. Can you show the output of "bt" in gdb? And do any of the examples crash?

Output of "bt"? What is this?
Well, the 'exgui.exe' worked with no problems. It could mean an invalid item in one of the GUI menus/whatever, since it crashes when I choose 'quit'.

It's not 'an error' in my code, but something 'unusual' to the library that causes such crash. I'll be tracking my GUI to see what's up.

Well, you posted some gdb output.. now, instead of typing "q" for quit, type "bt" for backtrace

Not much news... Is this a 'loop'?

Program received signal SIGSEGV, Segmentation fault.
0x67fece63 in clear_bitmap ()
(gdb) bt
#0  0x67fece63 in clear_bitmap ()
(gdb) bt
#0  0x67fece63 in clear_bitmap ()
(gdb) q
The program is running.  Exit anyway? (y or n) y

Hm, no, it means, gdb is somehow confused. try: "info threads" to list all threads - maybe that gives us a hint. Which gdb is this btw? I'm surprised you have a working gdb in windows.. but it's some time I tried to use it there myself, so things apparently improved

I assume, since exgui crashes, also other examples crash. I somehow can't help but think this is some sort of version problem, i.e. this isn't about clear_bitmap, but just the symbols got messed up or something.

9 threads? I find that is too much as well. Either your gdb just is broken, or something is completely wrong.

Try running the test program of allegro, and see if everything in it works, and if it also crashes on exit. Really can't think of anything else to try. If all the function in the test program work, but it crashes on exit, i'd say something is wrong with the way atexit() is used. (But I suspect, some of the tests will fail because the vtable is messed up and there is a version conflict after all.)

The same error occurred with:

Seriously, what could be wrong on compiling process? I downloaded the latest Allegro package (4.1.6 WIP), the latest MinGW (3.4.2 Candidate) in a new folder, then I compiled it and I'm getting this annoyance.

Well, you still didn't answer, is this specific to certain programs, or does it generally happen in every allegro program? I.e. they all work fine, but on exit, it crashes. Or do some crash earlier? Some not crash at all?

And compile the debug version of allegro, and also use debugging flags when you compile.. maybe that makes the gdb output more useful.

[Edit:] I don't think it has anything to do with compiling, unless it really is that modification you made to the makefile. Anyway, if you can, just try finding out whatever information you can (the two things I said above are just suggestions, don't really know if they will bring any useful info). But since this seems to be such a general bug (all apps crash) it somehow must be something special either with how you compiled allegro, or with your system, since it works for everybody else.

Also with tests/test.exe?

Did you try the debug version of Allegro? Run make clean and make DEBUGMODE=2 from the Allegro directory to rebuild with debugging symbols in place. This should make it easier to debug.

4.1.16.

This isn't fair...
It does NOT crash running the DEBUGMODE=2...

EDIT: It seems -mtune=i686 causes the problem. I tried -mtune=i586 (as replacement for -mpentium and it worked fine).

Hm, might investigate this in any case. Does it also crash with "march=athlon", or whatever is the Duron specific one?

I somehow believe this may be related to why /G7 doesn't seem to work with MSVC.

Well... no problems if "-mtune=athlon" is used. I switched back to "-mtune=i686" and the bug was back in action (select Quit -> crash). This is something that could be investigated & fixed.

Hmm... maybe you can output the assembler code with and without the switch, though I am not sure if the switch is for compiling or linking optimization.

"-mtune=<cpu>" is used during the compiling.
Well, I'm unable to do such thing, it's out of my average Anyway, here's the bug with "i686" option.