I've just updated to Allegro 4.1.16 and had the same problem as in this earlier thread (which was upgrading to 4.1.14):
[url http://www.allegro.cc/forums/view_thread.php?_id=378368]

Once I changed all the clear_to_colors to rectfills it worked fine. From reading the original thread again it seems that only Evert has also experienced this crashing bug. However maybe it is worth someone looking at?

Cheers!
Rich.

Does it crash when:

- clear_to_coloring a memory bitmap?
- clear_to_coloring the screen with the GDI driver?

If the answer is no to both, I suspect the problem to lie in the DirectX driver.

It crashes with clearing a memory bitmap, I'm not sure about the screen. I think it does, but I've not tried with a GDI driver.

Oh, with a memory bitmap - then it should be driver independent. I'll try it here in linux.

EDIT:

Just to be sure, does the below code crash for you?

#include <allegro.h>

int main(void)
{
    BITMAP *bmp;
    allegro_init ();
    set_color_depth (32);
    bmp = create_bitmap (100, 100);
    clear_to_color (bmp, 0);
    return 0;
}
END_OF_MAIN()

Yeah, but I have since changed my code to using clear_to_color() and clear_bitmap() again, and it works fine for me now.

This is something we should definitely fix though.

Well, first we should pinpoint down this a bit.. right now it can be anywhere. If the above does crash for Richard - it could be the asm code. If the above does not crash, it may be limited to a different color depth, or, ... well, no point speculating, just let's wait for the result.

It crashes.:'(

Does it crash with clear_bitmap() too?
It shouldn't make a difference, but it's good to know for sure

EDIT: just on the off chance that this changes anything, can you try calling set_gfx_mode() directly after allegro_init() and see if it still crashes?

No. It only crashes with clear_to_color.

WTF?!

From the Allegro source code:

/* clear_bitmap:
 *  Clears the bitmap to color 0.
 */
void clear_bitmap(BITMAP *bitmap)
{
   clear_to_color(bitmap, 0);
}

In other words... I don't understand this at all...

Oh, and see my edit above.

May I suggest recompiling Allergo?

Heh, WTF is all I can think as well.. I'd say, either something really weird is going on, or you mixed up the DLL version somehow.

When you compile without any -O option, it doesn't crash, right?

I've just upgraded from 4.0.3 to 4.1.16. I previously did the same with 4.1.13 and had the same problem, even after a couple of reinstalls.

Evert: Still crashes.

Is it possible that some 4.0.3 code is still in there? I've not had any other problems so far though..

EDIT:

Elias: Yes, any form of optimisation causes a crash, but it works fine without it.

You've removed all the old DLLs and libs, right?

I deleted the old allegro folder. Built the new lib. copied the dll into the source directory and wrote the Allegro version number to a logfile. That said 4.1.16.

Have you made a clean recompile of your project? When I change allegro versions, I always clean all object files for a project before recompiling. This is nescessary because WIP releases aren't API compatible.

Otherwise, can you reproduce the problems with the test program (allegro/tests/test)?

The test program works ok.

I did delete all object files, and your example was built from scratch Evert.

If the allegro library was built ok to be used by the test program, then is the error in linking with two different versions?

Possibly. Did you run a make uninstall from the previous version before installing the new one?

No. I've just done that now, and rebuilt allegro 4.1.16.

The crash example in one directory now seems to work ok. But my breakout game doesn't if I still use clear_to_color.

I'm wondering why it works without -O. The difference between clear_bitmap and clear_to_color is that with the former, inlining is done within the function in the DLL, while with the latter, inlining to bmp->vtable->clear_to_color is done when you compile.

So another question: Are you sure the headers in %MINGDIR%\include are from 4.1.16? The vtable struct may have changed, therefore bmp->vtable->clear_to_color points to some random memory and it crashes, but only when inlined.

EDIT:

Or, actually, when you executed "make install", did the MINGDIR variable point to the same directory which actually is used by mingw? I.e. if you have mingw in C:\mingw, and in C:\devcpp\mingw.. make sure MINGDIR points to the right one when doing "make install"..

Wouldn't make install copy all the relevant headers?

If you tell me which ones I need to copy manually I'll try that.

See edit. To manually copy, do this inside the allegro dir:

cp -r include/* MINGDIR/include/

(Sorry, don't know the windows way. But just copy everything in include into the mingdir include..)

The MINGDIR var is correct as far as I can tell.

I copied all the include files from the allegro include dir into the mingdir include dir. Recompiled all the project (deleting any old o files) and nothing has changed I'm afraid..

That makes me think... shouldn't the definition of clear_to_color() look like

AL_INLINE(void, clear_to_color, (BITMAP *bitmap, int color),
{
   ASSERT(bitmap && bitmap->vtable && bitmap->vtable->clear_to_color);

   bitmap->vtable->clear_to_color(bitmap, color);
})

rather than with only ASSERT(bitmap) as it is now?

Richard: could you try building a debug version of the library (DEBUGMODE=2) and see if you get assertion failures from that anywhere?

Hm. Still, the idea that wrong headers are included somehow seems to make sense to me, it would explain everything. How are you compiling (complete command-line)?

Can't think of anything else. Maybe, what does the below command say?
gcc --print-search-dirs

[EDIT]
Evert: I'd say, any non-NULL bitmap can be assumed to have a valid vtable. And any bitmap vtable should have no NULL entries.. but not so sure about that last point.

It works! It seems that I have an include folder in Dev-Cpp and an include folder in Dev-CPP/Mingw32.

It looks like Dev-c++ was using the Dev-CPP/Include one.

However I've noticed that the allegro version comes out as 4.1.14 rather than 4.1.16.

It likes like I have old junk left there.. Waah!

Curse you for using DevCPP! Use a MANS editor!

Haha. Just the typical devcpp-is-to-blame I wonder if the Allegro distributions could somehow be made more clever so they detect this. Maybe check in allegro_init if the DLL version and the header version is the same?

Maybe:

#define allegro_init() allegro_init_version_check(ALLEGRO_VERSION_STR)

allegro_init_version_check(char const *str)
{
    if (strcmp (str, ALLEGRO_VERSION_STR))
        allegro_message ("Wanring! Your headers version is different from the library version!");
}

Of course, this would need more than a simple strcmp, e.g. 4.0.0/4.0.3 would be ok.. but it would have detected this particular case at least.

Yes! I think this is a great idea, actually.

We can just skip the check if ALLEGRO_SUB_VERSION&1 is false.