Allegro.cc - Online Community

Allegro.cc Forums » Programming Questions » Vanille code crashes

This thread is locked; no one can reply to it. rss feed Print
Vanille code crashes
#00JMP00
Member #14,740
November 2012

I do this with 5.010:

#SelectExpand
1 2al_lock_bitmap (DTA); 3al_set_target_bitmap (DTA,al_get_bitmap_format(DTA),READwRITE); 4a_draw_filled_rectangle (0,0,300,300,al_map_rgb(0,0,0(int))); 5 6al_unlock_bitmap(DTA);

Code will crash reliably when drawing or clearing the bitmap.

Can someone help with this thing??

RPG Hacker
Member #12,492
January 2011
avatar

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

#00JMP00
Member #14,740
November 2012

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

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

RPG Hacker
Member #12,492
January 2011
avatar

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?

Elias
Member #358
May 2000

In fact [1] says:

Quote:

Note: While a bitmap is locked, you can not use any drawing operations on it (with the sole exception of al_put_pixel and al_put_blended_pixel).

--
"Either help out or stop whining" - Evert

Michael Moffitt
Member #15,246
July 2013

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

#00JMP00
Member #14,740
November 2012

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???????

RPG Hacker
Member #12,492
January 2011
avatar

#00JMP00 said:

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

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.

Quote:

At this current state it seems, it crashes without being locked too.

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).

#00JMP00
Member #14,740
November 2012

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

#SelectExpand
1 2#include <allegro...> 3#include ... 4#include... 5 6 7 8 9void clear_to_color (ALLEGRO_BITMAP *DTA,int r,int g, int b); 10 11void clear_to_color (ALLEGRO_BITMAP * DTA,int r,int g, int b) { 12 13 14// al_lock_bitmap (DTA,al_get_bitmap_format (DTA),ALLEGRO_LOCK_WRITEONLY); 15 16 17// al_set_target_bitmap (DTA); 18al_msg("farbe int"); 19 20// al_clear_to_color and al_draw_filled will both crash the program 21al_clear_to_color (al_map_rgb(r,g,b)); 22 23// al_draw_filled_rectangle (0,0,BM_W(DTA),BM_H(DTA),al_map_rgb(r,g,b)); 24 25al_msg("unlock"); 26// al_unlock_bitmap(DTA); 27return; 28 29} 30 31int main (vip arguments :-)) { 32 33 34ALLEGRO_BITMAP *SBB = al_create_bitmap (1024,768); // Values are somewhat unimportant 35 36clear_to_color (SBB,0,0,0); 37 38// Program will have crashed now 39 40 41 42}

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

RPG Hacker
Member #12,492
January 2011
avatar

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

#00JMP00
Member #14,740
November 2012

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 -

Edgar Reynaldo
Member #8,592
May 2007
avatar

#00JMP00
Member #14,740
November 2012

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.

Edgar Reynaldo
Member #8,592
May 2007
avatar

#00JMP00
Member #14,740
November 2012

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.

RPG Hacker
Member #12,492
January 2011
avatar

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.

#00JMP00
Member #14,740
November 2012

Quote:

Are you checking your pointers...

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.

RPG Hacker
Member #12,492
January 2011
avatar

#00JMP00 said:

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?

Dizzy Egg
Member #10,824
March 2009
avatar

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

al_set_target_bitmap

----------------------------------------------------
Please check out my songs:
https://soundcloud.com/dont-rob-the-machina

#00JMP00
Member #14,740
November 2012

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.

Dizzy Egg
Member #10,824
March 2009
avatar

I can't see al_get_bitmap_height in your code!?

----------------------------------------------------
Please check out my songs:
https://soundcloud.com/dont-rob-the-machina

#00JMP00
Member #14,740
November 2012

Then you have anther look and reread my last posting.

RPG Hacker
Member #12,492
January 2011
avatar

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

#00JMP00
Member #14,740
November 2012

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:

#SelectExpand
1 2 3int BM_H (allegro_bitmap *DBM) { 4 5 6return al_get_bitmap_height (DBM); 7}

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.

Edgar Reynaldo
Member #8,592
May 2007
avatar

Go to: