Array problems

1

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:

Callstack:

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++

Local:

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.

2

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

3

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

5

@Plutonium: It’s difficult to tell what the problem could be. I suggest you browse through Issues · HaxeFoundation/hxcpp · GitHub 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
6

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.

7

From checking the gc issues i tried MAX_MARK_THREADS=1 and it reduced the crashes. Still happening, but less often.
But only without pooling. Even when i use the lime.utils.ObjectPool, it creates funny null pointer issues :neutral_face:
But in debug mode with no polling, it works perfect. Sadly, release does not work that good… :expressionless:

8

If you can get an crash example that’s small then we can try to debug the cause

Another thing to try is to lower the compiler optimisation level which seems to be behind a crash on iOS

There’s also an experimental compiler flag HXCPP_CAPTURE_SETJMP that you can try

9

Hi, i failed in building a test case, but i found the issue: I am using akifox-asynchttp, which does http requests in different threads. I immediately used the data returned here, looks like it this was not the safest way…
Thx for your help!