[iOS] [ParparVM] Crash / Uncaught Signal during optDouble in JSONObject on iOS [bug]

[DurankGts]

Summary

Description:
Calling JSONObject.optDouble(String key, double defaultValue) causes a silent thread abort/native crash (EXC_BAD_ACCESS / SIGSEGV) on iOS when compiled with ParparVM, whereas it works as expected on the Simulator and Android.

Minimal reproducer

Description:
Calling JSONObject.optDouble(String key, double defaultValue) causes a silent thread abort/native crash (EXC_BAD_ACCESS / SIGSEGV) on iOS when compiled with ParparVM, whereas it works as expected on the Simulator and Android.

Steps to Reproduce:
Parse a JSON string into a JSONObject on iOS.

Call optDouble on a nested or root JSONObject passing a primitive or fallback double value, for example:

Java
JSONObject loc = geom.optJSONObject("location");
if (loc != null) {
// Code halts abruptly at this line on iOS
double lat = loc.optDouble("lat", -999.0);
}
Observe that execution stops immediately on that line without throwing a Java Throwable or reaching subsequent logging statements.

Steps to reproduce

Description:
Calling JSONObject.optDouble(String key, double defaultValue) causes a silent thread abort/native crash (EXC_BAD_ACCESS / SIGSEGV) on iOS when compiled with ParparVM, whereas it works as expected on the Simulator and Android.

Steps to Reproduce:
Parse a JSON string into a JSONObject on iOS.

Call optDouble on a nested or root JSONObject passing a primitive or fallback double value, for example:

Java
JSONObject loc = geom.optJSONObject("location");
if (loc != null) {
// Code halts abruptly at this line on iOS
double lat = loc.optDouble("lat", -999.0);
}
Observe that execution stops immediately on that line without throwing a Java Throwable or reaching subsequent logging statements.

Expected and observed behavior

Expected Behavior:
optDouble should return either the double value associated with the key or the fallback defaultValue provided, without crashing the execution thread on iOS.
Actual Behavior:
On iOS native builds, the call fails silently at the C/Objective-C transpilation level during unboxing/casting of the return value. Java try-catch (Throwable) blocks fail to catch the error because it triggers a native signal/memory access issue rather than a handled Java exception.

Codename One version

7.0.264

JDK version

17

Target environment

Framework: Codename One

OS: iOS 26 (Target Device)

Component: JSONObject / ParparVM (Bytecode-to-C Transpiler)

Last known working version

work perfect in ant structure

Logs and diagnostics

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]

The previous comments were done by a stupid LLM that wasn't given permission to do so... They were wrong.

Where does com.codename1.io.JSONObject I see https://github.com/shannah/CN1JSON/blob/master/src/ca/weblite/codename1/json/JSONObject.java but not com.codename1.io.JSONObject.

[DurankGts]

why you said stupid? The developers are not helping to best your core code? is logic the some LLMs present errors writting some times. But you need to understand the the Bug is Real. My code work perfectly before update my project to maven. Do you know the loss time to update an Simple app when I migrate to maven structure? It's difficult to migrate to maven and the some codes that work in ant structure now don't work in new VM in ios. The main problem is nothing exeption is throwed.

I hope that you understand

[shai-almog]

Not your issue comment. I had comments (that I deleted) that an LLM generated without asking me. They were stupid.

[shai-almog]

The bug is real but the class name you referred to isn't.

[DurankGts]

what was the violation of the LLM? the package wrong written? I just was testing a code that work well in ol VM, but in new VM fail silently. In ios is very dificult to found a problem compiling every time to build server to found a problem just printing a Log. this the reason of this to improve the debugging on device #5333

[shai-almog]

MY LLM not yours posted comments and closed the issue. It shouldn't have. Anyway, we can't fix this without looking at the class that triggered the failure. In your case you mention JSONObject we don't have that class so we can't fix the issue.

The evaluation from your LLM is also wrong, but I don't care about that. I just need the specific class that's failing. Not snippets.

[DurankGts]

tomorrow in the mourning I will pasted the class.

[DurankGts]

this the class ca.​weblite.​codename1.​json.JSONObject from extension cn1lib. You have integrated in you Core the Json?
I'm not going to risk switching to that class right now.
I found many problems migrating to maven that late various update of my apps in production.

[shai-almog]

This is a bug in that class, I suggest filing an issue against that project so @shannah will look at it.

This code is wrong:

 public double optDouble(String key, double defaultValue) {
 try {
 Object o = opt(key);
 return Double.parseDouble((String)o);
 } catch (Exception e) {
 return defaultValue;
 }
 }

o can be any object. Codename One's VM never implemented ClassCastException so this works in the simulator but fails on the device and this has always been true. In the past the failure might have been different due to other bugs or optimizations it's now worse. As a workaround, don't call optDouble. Call opt and do the cast yourself with instanceof guards.