BRL.Blitz and tdm-gcc-4.9.1
Archives Forums/BlitzMax Bug Reports/BRL.Blitz and tdm-gcc-4.9.1
| ||
| After recompiling modules with tdm-gcc-4.9.1 all programs got an access violation in release mode (debug mode works fine) in the startup of the blitz runtime. I traced this to a call to bbStringFromWString in bbStartup and further through bbGCAllocObject and bbGCFree which in turn called bbMemExtend with a NULL argument causing it to fail. This is really puzzling behavior, just by recompiling BRL.Blitz with a newer compiler (i used tdm-gcc-4.8.1 previously). Adding NULL checks to bbMemExtend solved this, but it still feels wrong. If anyone is able to debug this properly (mark?) and chime in, i would be grateful :) EDIT: This is in NON-threaded mode, using the RC gc. EDIT2: Just to clarify, calling bbMemExtend with NULL should cause it to fail anyway, since it manually allocates a new block, copies the old one over and frees it. why it doesnt care about this in debug mode or with previous compilers i have no idea... |
| ||
| Did you move the ld, ar commands to the Bmax/bin dir along with gcclib.a to the bmax/lib dir? Not sure if that's required. I'm using tdm 4.8.1 |
| ||
| If it helps, I can confirm that BlitzMax works perfectly on OSX with GCC 4.9.x, so whatever is causing this problem is presumably not on the upstream GCC side of things. |
| ||
| Yes, thats why im puzzled by this. Maybe il try using the runtime from C and see what GDB says, as i had to sprinkle printfs all over the place just to find that one. ;) |
| ||
| Can confirm the problem under Win8.1. This fixed it for tdm-gcc-4.9.2: blitz_memory.c
void *bbMemExtend( void *mem,int size,int new_size ){
void *p;
p=bbMemAlloc( new_size );
if(mem) {
bbMemCopy( p,mem,size );
bbMemFree( mem );
}
return p;
}
|
   |