Various glb.h bugs (ADDRESSOF and Local Array)

[spacefractal]

This one crashed in Spot Race when tried to compile the cpp to A files directly in xCode rather using the Windows Compiler. But this is not without some issues im have found doing this way and im not sure how to fix that.

ADDRESSOF():
#define ADDRESSOF(a) ((DGNat)((void*)&(a)))

should been:
#define ADDRESSOF(a) ((int64)((void*)&(a)))



Local Array Crash:

Here its crash on delete[] in those lines (in around line 626):

Code (glbasic) Select Expand


~DGArray() {
                if (pData) delete[] pData; pData=(T*)NULL;
#ifdef _DEBUG
dim= -787878; mem= -787878; count=-787878; max1=max2=max3=max4=fac2=fac3=fac4= -787878;
#endif
}


Its seen its LOCAL arrays that dosent work correctly and might memory leaks? Its say its trying to free a pointer that dosent got allocated. By now, im no clue how to fix that bug.

[kanonet]

ADDRESSOF problem is obvious for 64bit compile.

Did that array bug happen always and also when using GLB compiler+for other platforms? Also can you narrow it down to a simple test program, that fails always and is easy to reproduce?

[spacefractal]

It's happens when define array inside function as a local array and the function leave. When I'm changed it to uses a single global array, then all works fine.

[kanonet]

If its a local array and the function gets terminated, the array goes out of scope and the deconstructor (the code from glb.h that you posted) gets executed. Does this problem also happen on an array that was just created, but never used? Does this only happen on your 64bit compile tries, or is there any way I can reproduce this with standard GLBasic compiler (and without owning a Mac/iOS device)?

Gratz on Post #2000 BTW.

[spacefractal]

Cant test the 64bit versions yet (only ran in 32bit mode).

The array seens happens regaardsles it's was used or not. They was string me thinks and only with local array.

Yes it's happens in the deconstructor, but crash there.

It's workaroundable throught by not using local, but either static or global. This happens when used gcc compiler on Mac. Not sure it's happens on standard compiler, but don't thinks upside there.

[Kitty Hello]

Huh? How can the delete fail? Did you use elements out of bounds?

Gesendet von meinem GT-N7100 mit Tapatalk

[kanonet]

Its especially strange, since he said, that it even crashes when the array was just created, but never used!

[spacefractal]

its regaardles im uses them or not. Its was also happens when im scanned level which used a LOCAL array. Here its was also crashed on same line. Its like the destructor got called twice.

This is property a strange error.

[kanonet]

But it only happens on your compiler, which indicates that its probably not a pure coding error. Can enable more detailed compiler warnings or do some more tests to track it down? Maybe modify the code a bit for better test, like testing if the pData=NULL check fails for some reason, maybe print out pData etc.

[spacefractal]

all im did to get it working is change LOCAL arrays that used it (all was strings) to global array. So its actuelly in the end not that big deal for now.

[kanonet]

I dont agree, if such a basic thing fails, this is a big deal, no matter if you find a workaround. Could you try to simply create an array (no string) and see if that fails too?

[spacefractal]

im look about that later. Its can been due the newer c++ compiler im uses. its was something like this:

Code (glbasic) Select Expand


FUNCTION something:
LOCAL array$[]
DIM array$[10]
array$[0]="gdfgg"
ENDFUNCTION