Mingw Corrupted Executable

[sonich2401]

Compiling on Mingw-W64 x86_64-ucrt-posix-seh 11.2.0 causes the program to do undefined things such as crash when creating a const struct and corrupts data that is imported.

I am trying to include image and audio resources via Incbin and then placing them into a struct so I get the file size and the pointer to the data into one varible. This is done as follows

#define RES_INC(name, path) INCBIN(name, path); const struct file_struct s_ ## name = {g ## name ## Data, g ## name ## Size};

Looking at the program in gdb, it crashes when making the struct rater than the INC bin. It crashes at

__static_initialization_and_destruction0

This happens after the first included file was added successfully. The file_struct struct is as follows

struct file_struct { const unsigned char * data; size_t size; };

if I add a bunch of padding ints after each struct the program runs but other varibles that are in other .cpp files are being altered

[sonich2401]

Update: creating the structs at runtime now gives the error of a corrupt stack frame

Update2:

Removing all of my code and just keeping the incbin statements still crashes the program

[sonich2401]

I was able to give a "band-aid" fix to this by lagging the compiler. I was looking at the assembly generated by my program and it was writing the offsets of the data to be 0x52 and other random numbers. This was not relative from the instruction pointer but rather from 0x0. Usually, the assemby should show that the offset is 0x0 and the instruction should just look like this in binary

0x45 0x00 0x00 0x00 0x00

but it had something like

0x45 0x52 0x00 0x00 0x00

Usually the 4 zeros means that the linker will take care of it later and fill in what the address should be. My theory is that the inline assembler gives control back to the .c file but has not yet finished the .incbin statement. Therefor the data is not ready and the compiler just puts junk in there. Putting a bunch of statements that do nothing after the INCBIN statement seemed to fix everything so that is why I believe that. I dont know how compilers work so I could be wrong but I feel like that is a good theory.