I do this with 5.010:

Code will crash reliably when drawing or clearing the bitmap.

Can someone help with this thing??

Is there a special reason why you're locking the bitmap before drawing onto it?

Actually yes. The manual tells me to do it :-))

Where exactly? Can you put the link here?
al_draw_filled_rectangle, as the name suggest, should be a drawing operation. And drawing operations normally don't require you to lock the target bitmap. I couldn't find anything in the manual that says to lock the bitmap before calling al_draw_filled_rectangle. Where did you read that?

In fact ^[1] says:

I don't understand the confusion. You are very specifically doing drawing operations, which won't work on a locked bitmap.

Actually I thought, bitmaps have to be locked to keep them from being changed otherwise.

At this current state it seems, it crashes without being locked too. Later I will have another look at it.

Update

It is as stated above. It changed position a little - after returning from this routine - but the effect stays the same. Using draw/clear crashes the program.
Could it be something with incompatible linked libraries???????

Nah, locking a bitmap has nothing to do with "protecting" it. I have to admit that the terminology can be a bit confusing. When you lock a bitmap, everything that happens is that you map its memory to the CPU. So depending on how exactly you lock the bitmap, you can either read its pixel data that was previously on the GPU, write new pixel data to the bitmap on the GPU or do both.

Can you post your whole code? Aside from the locking, there is nothing obviously wrong with the code above (except for your usage of al_set_target_bitmap, which normally takes only one argument, but I don't think that's the problem here).

I post some of the relevant code. Posting the whole code wouldn't facilitate things.

To avoid the question in advance, the code crashes at runtime.

Did you initialize Allegro and all relevant sub systems? (with al_init() etc.)

I guess yes.

I omitted this point and continued my way through the code.

Now I unearthed another issue:

Assertion failed: bitmap != destination && bitmap != dest->parent, coming along
with a none existing path, ending "allegro-git\src\bitmap_draw.c line33".

- It makes me wonder -

It says 'make sure the source bitmap is not a sub bitmap of the destination and make sure you're not drawing to yourself', basically. So you're doing one of those two things somehow.

Yes, I figured that out - thank you anyway.

The assertion failure is gone, but it still crashes. The assertion was
somewhat blind.

Maybe I get rid of the rest too.

Use a debugger like GDB or MSVS built in debugger. Get the stack / backtrace from where it crashes, and then you can see why it is crashing by examining local variables usually.

Using the debugger, once setup, was easier than thought. Unfortunately the come out wasn't worth the effort.

The error seems to change position sometimes. At the end I can tell, that location and/or size of an object (bitmap) shall be resolved. Last registered access is to ntdll.dll and allegro.../bitmap.c. There the value 0x0 is returned. I guess the value shouldn't be 0x0, thus crashing the program.

All object are in good order :-) and I do not understand this behaviour.

Update:

I found, when I use my function BM_h() - returning height of a bitmap, there will be a wrong value. Just now, program crashed with -5901xxxxx. I guess negative values are not possible.

Hmmm.

Are you checking all your pointers for NULL before doing anything with them? It sounds like you could accidentally be passing a NULL pointer into a function that doesn't support NULL pointers, thus the crash. I'd check that.

I did and they where ok. Besides this, they are initialised and in use, though code would crash at other position.

Additional question

As I posted above, the assertion failed pointed to a none existing allegro ressource. Why is this? The path to the object requested d:/librariers/allegro... ist completely none existing and probably never existed before.

This probably refers to a path on the system the Allegro libs were build on. Or did you build the libs yourself?

You've got to tell your 'clear_to_color' function which BMP it should be clearing!!

al_set_target_bitmap

There it was, but then has been outcommented :-))

It doesn't work anyway.

There still occurs an error when calling al_get_bitmap_height, in my version.

Error is still at ntdll.dll/allegro/bitmap.c.

Someone said, pointer is probably NULL, but the bitmap is set, since
the size can be read at other position. Looking at the debugger error,
it really seems to be this, but I can't change it.

I can't see al_get_bitmap_height in your code!?

Then you have anther look and reread my last posting.

I did. There IS no al_get_bitmap_height in the code you posted above.

Well, op was refering to al_set_target_bitmap...

therefore I was refering to this.

But at a closer look, even al_get_bitmap_height is there,
somewhat coated by a shorter version:

To eliminate the possibility of a problem here, I hand
wrote it in my version...

I actually would't want to put my code here.

If al_get_bitmap_height is returning crazy values it is because you are calling it on an uninitialized or dangling ALLEGRO_BITMAP*.