read file from memory DEBUG vs RELEASE

[Iyad]

Hi,
I am visual studio c++ 2019, and building a small app using irrlicht.
My app is portable so I embed my data inside the program using bin2h.

With bin2h I managed to transform my password encrypted ZIP file into a unsigned char[] :

Code: Select all

 
unsigned char resources_data[]={
0x50,0x4b,0x03,0x04,0x33,0x00,0x01,0x00,0x63,0x00,0xa8,0x7d,0x30,0x51,..........
 
(cut 20k lines after...)
 
,0x76,0x02,0x00,0x00,0x2b,0xf0,0x03,0x00,0x00,0x00,0x00};
unsigned int data_size=398541;
 

I put this in embedded.h and load it from memory:

Code: Select all

 
io::IReadFile* files_archive = device->getFileSystem()->createMemoryReadFile(resources_data, data_size, "mydatafile.zip", false); 
device->getFileSystem()->addFileArchive(files_archive, true, true, io::EFAT_ZIP, "mypassword");
 

It works withouyt any issue in DEBUG mode,

Code: Select all

 
Reading encrypted file.
Reading encrypted file.
Loaded texture: myfontd.png
Reading encrypted file.
Loaded texture: image1.png
Reading encrypted file.
Loaded texture: image2.png
Reading encrypted file.
Loaded texture: image3.png
Reading encrypted file.
Loaded texture: image4.png
 

However when building in release mode :

Code: Select all

 
Reading encrypted file.
Reading encrypted file.
Could not load texture: myfontd.png
Unable to load all textures in the font, aborting
Reading encrypted file.
Reading encrypted file.
Could not load texture: image1.png
Reading encrypted file.
Could not load texture: image2.png
Reading encrypted file.
Could not load texture: image3.png
Reading encrypted file.
Could not load texture: image4.png
 

I tried to use FileSystem->ChangeWorkingDirectory("./");

Is it a bug? I checked the differences between my debug and release configs and can't seem to understand what happened.
I tried also linking in my release build the debug build of Irrlicht (the same that works) and still get the same issue.

does it have to do with irrlicht? visual studio? compiler optimization?

Thanks

[CuteAlien]

Sorry, not enough information to tell. This needs to be reproducible to start debugging. You might want to start with a simple zip - as minimal as possible (single small file, no password) and check if that works. If not - you can maybe post that specific header file you created and the full code to load it. Then it should be possible for me to reproduce it.

[Iyad]

Hi,
thank you for your fast answer,
I don't think it has to do with the header file, its raw hex data, since I manage to load the data in memory and open it in debug mode it should also load it in release mode. Nothing changed in the file, only the build I selected in VS with its configuration and the irrlicht DLL (debug and release build).

I tried changing every option in the release mode to match with the debug to see if what kind of optimization/parameter changed but without success.

Also my zip file is quite small, only 4 files and 250kb zipped, encrypted with AES. As I said; when building my project in release mode, it fails to load the files (but reads the zip archive correctly), as if the path were not added when i added the archive to irrlicht, the debug mode works fine.

I managed to make it work, but not as I wanted:
I had to use the debug build of irrlicht DLL. There is probably some optimization or something in the irrlicht code, since when I use the debug built of irrlicht DLL I manage to read the files correctly. The Release DLL of irrlicht fails to load the files. I didnt change anything in my code (up), I only change the irrlicht DLL and im using the debug one.

so it's solved but not really,
thanks anyways!

[CuteAlien]

I also don't think it's caused by a specific header. I just recommend getting a reproducible example. This can include the project file. But it should be minimal. Meaning - you can't remove anything anymore without losing the crash. If it happens with the tiniest, simplest possible zip then it reduces the amount of things which can cause it. For example you say it's still encrypted. Very first thing I'd try is if it also happens with a zip without encryption.

And then you can post it and others can look at it.

The info so far is not enough to have an idea where to start looking. In most cases such bugs are not even related to the engine, but often stuff like an unitialized pointer somewhere in the user code.