Array problems

Hi! I recently ported a flash game to html with haxe, works fine. Now i’m trying to create windows / android version. Here i ran into problems with lots of nullpointer exceptions. I used object pooling ( stored common objects in arrays ) - after removing that it became more stable, but still with random crashes( only in release mode of course).
But now i got a crash in the Array itself, which could be related. Not sure if this is a bug or if i’m doing something wrong:


hx::TestLessEq<0,1,Dynamic,Dynamic>(const Dynamic & v1, const Dynamic & v2) Zeile 393	C++
hx::IsEq<Dynamic,Dynamic>(const Dynamic & v1, const Dynamic & v2) Zeile 404	C++
hx::DynamicEq(const Dynamic & a, const Dynamic & b) Zeile 730	C++
hx::arrayElemEq<Dynamic>(const Dynamic & a, const Dynamic & b) Zeile 461	C++
Array_obj<Dynamic>::remove(Dynamic inValue) Zeile 649	C++


diff	-1	int
+		o1	0x0000000000000000 <NULL>	hx::Object *
+		o2	0x000001c37f733190 {mCB={...} tickTime=51357 }	hx::Object * {_hx_system::clock::DelayData_obj}
+		v1	{...}	const Dynamic &
+		v2	{...}	const Dynamic &

How can this happen? It is not easy to reproduce, i was not able to create a test case.

Sounds like some GC issue. What Haxe and hxcpp versions are you using?

It is haxe 4.0.0-rc.4 and hxcpp 4.0.52.

(post withdrawn by author, will be automatically deleted in 24 hours unless flagged)

@Plutonium: It’s difficult to tell what the problem could be. I suggest you browse through✓&q=is%3Aissue+is%3Aopen+gc to see if any of these issues is similar.

@Zhan: Your comment isn’t helpful in any way. Please refrain from such remarks.

1 Like

It’s pretty certain that this is related to garbage collection which is probably why the problem appears to be random. I’ve usually encountered this sort of thing relative to “stale pointers” – where some object is harboring a pointer to something that got garbage-collected. (In this case I’m not specifically talking about Haxe …)

The scenario that I have in mind arose from copying a pointer to a garbage-controlled object in a way that did not increment the object’s reference-count. So eventually the object “got reaped” and the pointer thereby became “stale.” And the real problem is that this won’t cause any actual crash unless the garbage-collector maps the storage-page out of the process’s address-space. A crash is easy to detect, but a pointer that “still points to something that’s addressable, but is no longer the right thing” is not.