[Bug] ios builds crash

[ddyer0]

Summary

I strongly suspect this is a regression related to all the other memory management/gc problems
we've been exploring. The scenario is that near the END of a deep and garbage-heavy search,
my ipad simply crashes with no warning. The same build works fine under xcode+simulator
and also on android and windows simulator. I strongly suspect the app is running out of
memory or triggering your low memory warning, with unexpected results.

Minimal reproducer

At present, the only way to produce this is in the real boardspace.net app. Just play a game of Gomoku
against a robot.

Steps to reproduce

difficut

Expected and observed behavior

The hard crash ought to not occur. If that were accomplished debugging everything else would
be a lot easier.

Codename One version

current release

JDK version

n/a

Target environment

ios

Last known working version

depends on a deep search.

Logs and diagnostics

I wish.

Screenshots or recordings

No response

Report checks

• I searched existing issues and discussions for this behavior.
• The reproducer contains no credentials, signing keys, or private customer data.
• I understand that triage is not a commitment to a fix date.

[shai-almog]

We need a manageable test case. I'd guess this might relate to this: #5531 which is code that relies on class cast semantics of the JVM. In the past it used to fail in a more subtle way and now it crashes. So it's possible there's code like that hiding within the project.

[ddyer0]

trying to debug on ipad under xcode control, the app crashes with this error
Library not loaded: '/System/Library/Frameworks/OpenGLES.framework/OpenGLES'
Referenced from: '/private/var/containers/Bundle/Application/C2F0EC11-6101-4FDD-A391-4865B338F563/Develop2.app/Develop2'
Reason: tried: '/System/Library/Frameworks/OpenGLES.framework/OpenGLES' (no such file)

this is a metal build, so opengl shouldn't be referenced. The actual app, not debugging under xcode,
doesn't have this particular problem.

[ddyer0]

I got this by attaching a debugger. Looks like something along the lines I expect.

[ddyer0]

I want to help you fix this, but if I do as before and generate a giant single file, it wont be significantly simpler to understand than my whole application. You could easily do the same debugger trick from a binary I supply instead of a giant source file.

The overall behavior of the process that fails is that it is completely CPU bound, with a lot of short lived small objects but low peak memory use and almost no long lived objects.

I feel like I'm single handedly keeping your bug queue filled. No need to thank me.

[shai-almog]

This is an out of memory crash. I have a theory about what might cause it. If you add some sleep code in your heavy allocation loop there does it workaround the problem?

For future cases I can work with a symbolicated crash dump. But attach it don't embed it in a comment as that makes the issue impossible to read. In this case I don't need it though.

[shai-almog]

This is an out of memory crash. I have a theory about what might cause it. If you add some sleep code in your heavy allocation loop there does it workaround the problem?

For future cases I can work with a symbolicated crash dump. But attach it don't embed it in a comment as that makes the issue impossible to read. In this case I don't need it though.

[ddyer0]

How much sleep ? Or just enough to yield control?

[shai-almog]

Try a little. If it doesn't help try a bit more. Generally gc runs periodically but should detect memory pressure and recover.

[ddyer0]

small (1ms) or meduim (100ms) pauses every so often don't fix the problem, but longer pauses
seem to get a bit further. Excessively long pauses (1000 ms) allow it to succeed, although pauses
of that length probably altered the flow because of time control logic.