Resizable arrays with Externed C objects

BlitzMax Forums/BlitzMax Programming/Resizable arrays with Externed C objects

JoshK(Posted 2012) [#1]
I was getting a reliable crash on GCCollect and I traced the problem back to some resizable arrays of an externed C type. I created a BMC wrapper type to store these in instead of directly putting them in the array.

Can the compiler please generate an error if the user tries to do this, if it isn't meant to be supported?


Noobody(Posted 2012) [#2]
I couldn't entirely figure out your setup from your post - can you post a minimal version showing the problem?


JoshK(Posted 2012) [#3]
I can't reproduce the problem in a simple example, but what I mean is this:
Extern "C"

	Type Thing
	EndType

EndExtern

GCSetMode 2

Local array:Thing[]

For n=1 To 10000
	array = array[..Rand(1,1000)]
Next

GCCollect

Print "OK"



AntonyWells(Posted 2012) [#4]
unless my mind is asleep, ..<value> is a slice operation. so array=array[..rand(1,1000)]

wouid probably crash instantly as nothing has been produced yet.

use

local array:Thing[] = new Thing[10000]

first,

then fill it with objects.


col(Posted 2012) [#5]
I understand thats a cut down example but assuming that the array is already initialised with valid data so you are simply resizing an existing valid array...

My understanding is that when you resize an existing array, internally a new array is constructed in memory then the contents copied across. This would mean the old array needs garbage collecting.

So you're resizing the same array many times, adding lots of old arrays to be collected. When it gets too much too quick then BOOM when the GC kicks in.

I had the exact same issues in the d3d11 driver when an array might be rebuilt many times in quick succession, even once per frame, but over many frames changing size every frame.

The only solution I could find was to do a GCCollect() immediately AFTER each resize and not let it accumulate over many frames.

Possibly a bug?

Is turning the GC off just part of your example or are you doing it that way in the project code?

Last edited 2012


JoshK(Posted 2012) [#6]
I am saying I think that externed C objects are different from BlitzMax objects, and I believe resizable arrays with Externed C objects produce some kind of memory overwrite error that moves around in memory and is not easily reproducible.

If you don't believe me, that's fine, because I have not demonstrated a bug, but I think this is the case and will always proceed with that assumption in all my code from now on.

Last edited 2012


Jesse(Posted 2012) [#7]

unless my mind is asleep, ..<value> is a slice operation. so array=array[..rand(1,1000)]

wouid probably crash instantly as nothing has been produced yet.



No, no crash.

arrays are objects themselves so that might be the reason why they don't work directly with c.
best thing to do is to look in to the "blitz_array.c and " and "Blitz.h" under "Blitz.mod". Might help you clear it up.

Last edited 2012