Re: [AD] Failed call to inflate inside physfs when loading bmp from zip

On Sun, Apr 30, 2017 at 5:30 PM, Edgar Reynaldo <edgarreynaldo@xxxxxxxxxxxxxxxxxx> wrote:

Hi people.

I recently built some binaries for Allegro 5.2.3 and Neil Roy tried them out and discovered that his ttf files inside his zip file no longer load in his Deluxe Pacman 2 game using physfs.

Similarly, ex_physfs fails without reporting any errors. 02.bmp fails to load from inside the ex_physfs.zip file under the data folder.

The bitmap is failing to load because of a cascade of errors.

The error is because al_fseek fails in the call to _al_load_bmp_f on line 1320 of addons/image/bmp.c.

al_fseek calls file_phys_seek, which calls PHYSFS_seek, which calls ZIP_seek, which calls ZIP_read, which fails in physfs-2.0.3\archivers\zip.c on line 258.

Ultimately, it's a call to inflate (from the libphysfs.dll library) that fails and returns -2, which I think means there was a stream error.

Here's the backtrace :

Breakpoint 9, 0x64a1876c in inflate () from c:\LIBS5303Distro\Allegro522_MinGW5303\bin\dlls\libphysfs.dll
(gdb) bt
#0 0x64a1876c in inflate () from c:\LIBS5303Distro\Allegro522_MinGW5303\bin\dlls\libphysfs.dll
#1 0x64a0fb24 in ZIP_read (opaque=0x12ea4d8, buf=0x61eaa8, objSize=118, objCount=1)
at C:\LIBS5303Build\physfs-2.0.3\archivers\zip.c:258
#2 0x64a0fe28 in ZIP_seek (opaque=0x12ea4d8, offset=118) at C:\LIBS5303Build\physfs-2.0.3\archivers\zip.c:343
#3 0x64a0508c in PHYSFS_seek (handle=0x5060798, pos=118) at C:\LIBS5303Build\physfs-2.0.3\physfs.c:2066
#4 0x67891e7e in file_phys_seek (f=0x12eb030, offset=118, whence=0)
at C:\LIBS5303Build\allegro5\addons\physfs\a5_physfs.c:214
#5 0x677a74b1 in al_fseek (f=0x12eb030, offset=118, whence=0) at C:\LIBS5303Build\allegro5\src\file.c:175
#6 0x67871860 in _al_load_bmp_f (f=0x12eb030, flags=0) at C:\LIBS5303Build\allegro5\addons\image\bmp.c:1320
#7 0x678726db in _al_load_bmp (filename=0x40b1ee <__register_frame_info+4239854> "02.bmp", flags=0)
at C:\LIBS5303Build\allegro5\addons\image\bmp.c:1596
#8 0x67783ffd in al_load_bitmap_flags (filename=0x40b1ee <__register_frame_info+4239854> "02.bmp", flags=0)
at C:\LIBS5303Build\allegro5\src\bitmap_io.c:209
#9 0x67783f39 in al_load_bitmap (filename=0x40b1ee <__register_frame_info+4239854> "02.bmp")
at C:\LIBS5303Build\allegro5\src\bitmap_io.c:184
#10 0x00401a8c in main (argc=1, argv=0x12e8130) at C:\LIBS5303Build\allegro5\examples\ex_physfs.c:165

However, ex_physfs from Allegro 5.2.1.1 does not have this problem, and it can load the same zip file and bitmap just fine. I tested it with the zip file from 5.2.3.

I built both versions of Allegro with PhysFS 2.0.3. The only thing that was different was the version of zlib. With Allegro 5.2.1.1 I used Zlib 1.2.8 and with Allegro 5.2.3 I used Zlib 1.2.11.

So there is either a bug in Allegro or a bug in zlib. I don't really know where else to go from here at this point, so I'm looking for a little guidance.

This is a far as I can get with my debugging skills. I don't know what else to do.

inflate is returning -2, which means it's not equivalent to Z_OK, which means it bails out of the read.

(gdb) n
Single stepping until exit from function inflate,
which has no line number information.
ZIP_read (opaque=0x12ea4d8, buf=0x61eaa8, objSize=118, objCount=1)
at C:\LIBS5303Build\physfs-2.0.3\archivers\zip.c:259
259 retval += (finfo->stream.total_out - before);
(gdb) l
254 finfo->stream.avail_in = (PHYSFS_uint32) br;
255 } /* if */
256 } /* if */
257
258 rc = zlib_err(inflate(&finfo->stream, Z_SYNC_FLUSH));
259 retval += (finfo->stream.total_out - before);
260
261 if (rc != Z_OK)
262 break;
263 } /* while */
(gdb) p rc
$16 = -2

Please advise.

Edgar