test_driver: renamed image refuses to load

test_driver: renamed image refuses to load

weapon_S

Member #7,859

October 2006

Because my installation lacks jpeg, I edited some ini files for test_driver. Namely: test_image (removed jpeg sections), and test_prim (changed file name for obp). For the latter of course I also saved a copy of the file in an another format. Still it failed (gracefully) to load the third bitmap. I have tried bmp (24 or 32 bit), and png with some random settings (desperately tried turning down compression). I don't see why the image won't load.
I ran it through gdb, and it justs fails to fopen the third file. (Notice the previous two images were loaded without problem.)
So here's the first few lines of the ini (only first 3 are of importance):

[bitmaps]
bkg=../examples/data/bkg.png
texture=../examples/data/texture.tga
obp=../examples/data/obp.bmp

[ll]
op0= al_draw_bitmap(bkg, 0, 0, 0)
op1= al_build_transform(trans, 320, 240, 1, 1, 1.0)
op2=
op3= al_set_blender(ALLEGRO_ADD, ALLEGRO_ONE, ALLEGRO_ONE)
op4= al_use_transform(trans)
[...]

(I asserted the line ending and non-printing characters)
Here's my first attempt at debugging it:

#SelectExpand
  1(gdb) list
  220
  321         ASSERT(drv);
  422         ASSERT(path);
  523         ASSERT(mode);
  624
  725         if (drv->fi_fopen) {
  826            f = al_malloc(sizeof(*f));
  927            if (!f) {
 1028               al_set_errno(ENOMEM);
 1129            }
 12(gdb) step
 1326            f = al_malloc(sizeof(*f));
 14(gdb)
 15al_malloc_with_context (n=28, line=26,
 16    file=0x6942d1c8 "D:\\SDevX\\A5\\src\\file.c",
 17    func=0x6942d28e "al_fopen_interface") at D:\SDevX\A5\src\memory.c:41
 1841         if (mem)
 19(gdb)
 2044            return malloc(n);
 21(gdb)
 2245      }
 23(gdb)
 24al_fopen_interface (drv=0x6942d340,
 25    path=0x1dd6fb8 "../examples/data/obp.bmp", mode=0x6316e117 "rb")
 26    at D:\SDevX\A5\src\file.c:27
 2727            if (!f) {
 28(gdb)
 2931               f->vtable = drv;
 30(gdb)
 3132               f->userdata = drv->fi_fopen(path, mode);
 32(gdb)
 33file_stdio_fopen (path=0x1dd6fb8 "../examples/data/obp.bmp",
 34    mode=0x6316e117 "rb") at D:\SDevX\A5\src\file_stdio.c:82
 3582         fp = fopen(path, mode);
 36(gdb) print path
 37$4 = 0x1dd6fb8 "../examples/data/obp.bmp"
 38(gdb) print mode
 39$5 = 0x6316e117 "rb"
 40(gdb) step
 4183         if (!fp) {
 42(gdb)
 4384            al_set_errno(ENOMEM);
 44(gdb) list
 4579      {
 4680         FILE *fp;
 4781
 4882         fp = fopen(path, mode);
 4983         if (!fp) {
 5084            al_set_errno(ENOMEM);
 5185            return NULL;
 5286         }
 5387
 5488         return fp;

Allegro 5.1.2.0 debug. Build without SSE. MinGW 4.5. Windows 7. I've tried a fresh restart.
The only thing I can think of is some illegal access to memory used by fopen. :-/
Any more sensible ideas?

Yes well, legibility and correct punctuation might not be "street"... but that's how I roll, motherfucker. -Edward.
Yes it sounds more authoritative to invoke some cute phrase every few sentences, but it doesn't actually make an argument any more impressive. Matthew Leverton

Arthur Kalliokoski

Second in Command

February 2005

If you swap the order of files around, the third one always fails?

They all watch too much MSNBC... they get ideas.

Peter Wang

Member #23

April 2000

Make sure the obp.bmp exists in the $BUILDDIR/examples/data, where $BUILDDIR is your build directory. It won't work to just have it in the source examples/data directory.

weapon_S

Member #7,859

October 2006

D'OH! Now I feel stupid. I was confused because the ini files are only in the source directory.
Rule #1 of debugging: the least trustworthy needs the closest inspection.