It is a 5-year-old issue that was not bothering me much with my pet projects. Till I started playing with something big. In result with my default 4GB heap setting for Idea I was not able to complete a build due heap exhaustion:

Things got better with 8GB heap settings:

This issue was mentioned multiple times over all channels and all reports have the following in common:

• issue usually was seen in crash reporters;
• no steps or information how to reproduce;
• no simple project to reproduce;
• production source code can’t be shared for investigation;
• crash is related to heavy network activities;
• crash log looks similar to bellow:

rvmCreateVM
SIGABRT ABORT 0x00000001d5219414

Crashed: Thread
0  libsystem_kernel.dylib         0x1d5219414 __pthread_kill + 8
1  libsystem_pthread.dylib        0x1f2d74b50 pthread_kill + 272
2  libsystem_c.dylib              0x1b06f7b74 abort + 104
3  RoboVMMobile                   0x1060a77b0 rvmCreateVM + 4386699184
4  RoboVMMobile                   0x1060a51ec rvmInitialize + 4386689516
5  RoboVMMobile                   0x10609d9a8 _bcInitializeClass + 4386658728

Things changed once Benjamin Schulte @MrStahlfelge reported unknown rare crash that was happening approximately once per 100 launches and ErgoWallet is opensources. 1 crash per 100 launches sound good to track the bug.

Root case

Issue mentioned in report #641 Code is quite simple to reproduce:

package a;
public class A {
    protected void foo(){};
}

package b;
import a.A;
public class B extends A {
    public void test() {
        Runnable r = this::foo;
        r.run();
    }
}

Root case

Xcode13.3 bring unaligned pointer problem during linking but also debugger launch was crashing with:

[ERROR] Couldn’t start application java.lang.IllegalArgumentException: there is no region for addr @10000101effaa0 at org.robovm.debugger.utils.bytebuffer.CompositeDataBuffer.setPosition(CompositeDataBuffer.java:37)

0x10000101effaa0 indeed looks weird for memory address, even looks like tagged pointer at first (but not). Anyway it introduced a level of complication that is not allowing debugger to read internal RoboVM structures like class info anymore.

LC_DYLD_CHAINED_FIXUPS and LC_DYLD_EXPORTS_TRIE

This issue is rare and affects most user. It can be seen once registered for default Java exception handler.
Scenario for this crash is following:

• iOS application goes to background/suspend (just enough to minimize it);
• resumed after > 10s.

Crash is rare but more user you have more crashes you will see.

Root case

FinalizerWatchdogDaemon looks after FinalizerDaemon and responsible to terminate App if object spends too much time in .finalize() call. Scenario is following:

• FinalizerDaemon picks object to dispose and calls .finalize() to allow object performing clean-ups;
• FinalizerWatchdogDaemon detects it and startes looking for it;
• Application is minimized/suspended;
• all threads are suspended (including Daemons);
• (time passed, 10+ seconds);
• Application is resumed;
• .finalize() is still busy;
• FinalizerWatchdogDaemon has already counted 10+ seconds its being observing class doing finalization and terminates app, considering that finalizer is stuck.

Trying to reproduce

AltPods were updated to v1.22.0-SNAPSHOT to sync with recent releases.

Updated pods

• Adaptry 1.16.9 to 1.16.10
• AppCenter 4.4.1 to 4.4.2
• AppLovinSDK v11.3.1 to v11.3.3
• Facebook v13.0.0 to v13.1.0
• Firebase v8.13.0 to v8.14.0
• OneSignal v3.10.1 to v3.10.2
• Singular v11.0.4 to v11.0.6
• UnityAds v4.0.1 to v4.1.0

These pods were pushed to https://oss.sonatype.org/content/repositories/snapshots maven repo under 1.22.0-SNAPSHOTS version. Source code @github

Updates are not fully tested, please open issue if bug found.

Xcode started complaining about unaligned pointer in RoboVM binaries since 8.3 (issue #123) but these warnings (altogether with other possible) were suppressed with -w option. But with Xcode13.3 it started failing with error ld: unaligned pointer(s) for architecture arm64 on some projects (while compiled ok but probably with changes to it might fail).

Trying to reproduce

Idea plugin is not available at Idea Marketplace yet as in review!
But can be downloaded manually from MobiVM site.

2.3.16: What’s new

• Fixed: ‘duplicate symbol xxx.spfpoffset’ in debug build when using GoogleMobileAds pod PR626
• Framework target: can produce XCFramework, can produce m1 simulator slice PR624
• Fixed: missing bitcode in VM libs (introduced by m1 support changes) PR624
• Fixed #621 – hang of SKStoreReviewController.requestReview by PR615. WARNING: window is to be retained in user code now !!!
• ByteBuffer J9 API desugaring PR615
• ios15 binding PR613

2.3.17-SNAPSHOT:

• Fixed: missing simulator arch in Idea picker PR642
• New: ios15.4 bindings PR635
• Changes: to swiftSupport configuration parameter PR638
• Changes: Debugger – can suspend any thread PR628

Happy coding!
Please report any issue to tracker.

AltPods were updated to v1.21.0-SNAPSHOT to sync with recent releases.

Updated pods

• AppLovinSDK v11.1.0 to v11.2.1
• Facebook v12.3.1 to v13.0.0
• Firebase v8.11.0 to v8.13.0
• Fyber v8.1.2 to v8.1.4
• Kochava v5.1.0 to v5.1.1
• OneSignal v3.10.1 to v3.10.0
• Singular v11.0.3 to v11.0.4
• UnityAds v4.0.0 to v4.0.1

New pods

• IronSource v7.2.1

These pods were pushed to https://oss.sonatype.org/content/repositories/snapshots maven repo under 1.21.0-SNAPSHOTS version. Source code @github

Updates are not fully tested, please open issue if bug found.

RoboVM code can be stopped only when code reach instrumented hook callbacks (ones that being injected after every line by compiler). As result pausing application will in most cases not stop the application and will not show valid call stack:

Root case

• Thread state is not delivered from VM to debugger so always reported as running;
• “Paused” thread doesn’t show any call stack due no ability to pause it other places than instrumented hooks code;

Approach