<html><head><meta http-equiv="content-type" content="text/html; charset=utf-8"></head><body style="overflow-wrap: break-word; -webkit-nbsp-mode: space; line-break: after-white-space;"><div>I entered a bug <a href="https://bugs.openjdk.org/browse/JDK-8351733">https://bugs.openjdk.org/browse/JDK-8351733</a>.</div><div><br></div><div>This crash doesn’t happen if you create nested event loops while processing events. I wrote a test app that started a new event loop on every mouse click and easily created over 400 nested loops. So we’re not pushing up against the native thread stack size limit, we’re running into an undocumented limit on the number of nested CFRunLoopRun calls. There’s a line to that effect in the crash log (which I overlooked for a while because I’m not used to crash logs being that helpful).</div><div><br></div><div>The bug is specific to the way the Mac handles runLater blocks and other internal uses of performSelectorOnMainThread. So far I can only reproduce this using Platform::runLater e.g. block A schedules runLater block B and then enters a nested event loop, block B schedules runLater block C and enters a nested event loop, and on and on. In a real app it’s also possible that some internal uses of performSelectorOnMainThread might be interacting with Platform::runLater calls in unexpected ways.</div><div><br></div><div>As far as I know here’s no way to ask the system what the CFRunLoopRun nesting limit is and no way to detect at runtime when we’ve hit it. The best we can do is maintain an internal counter and throw a runtime exception when it hits, say, 245 nested CFRunLoopRun calls. That at least would produce a very long but usable Java stack trace.</div><div><br></div><div>I could update <span style="font-family: Optima-Regular;">Platform::canStartNestedEventLoop</span><font face="Optima-Regular"> to detect this case but I’m not sure it would be useful. When you hit this condition the system will already be 240+ loops in and they will all have to be unwound to get the system back into a usable state.</font></div><div><br></div><div><font face="Optima-Regular">Adding the code to glass that throws an exception and writing up a manual test case is easy. Writing up an automated test case is much harder (at least for me).</font></div><div><br></div><div><div><div><blockquote type="cite"><div>On Mar 10, 2025, at 7:47 PM, Christopher Schnick <crschnick@xpipe.io> wrote:</div><br class="Apple-interchange-newline"><div><meta charset="UTF-8"><p style="caret-color: rgb(0, 0, 0); font-family: Optima-Regular; font-size: 14px; font-style: normal; font-variant-caps: normal; font-weight: 400; letter-spacing: normal; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; word-spacing: 0px; -webkit-text-stroke-width: 0px; text-decoration: none;">Our code and some libraries do enter some nested event loops at a few places when it makes sense, but we didn't do anything to explicitly provoke this, this occurred naturally in our application. So it would be nice if JavaFX could somehow guard against this, especially since crashing the JVM is probably the worst thing that can happen.<br><br>I looked at the documentation, but it seems like the public API at Platform::enterNestedEventLoop does not mention this.<br>From my understanding, the method Platform::canStartNestedEventLoop is potentially the right method to indicate to the caller that the limit is close by returning false.<br>And even if something like an exception is thrown when a nested event loop is started while it is close to the limit, that would still be much better than a direct crash.<br><br>Best<br>Christopher Schnick<br></p><div class="moz-cite-prefix" style="caret-color: rgb(0, 0, 0); font-family: Optima-Regular; font-size: 14px; font-style: normal; font-variant-caps: normal; font-weight: 400; letter-spacing: normal; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; word-spacing: 0px; -webkit-text-stroke-width: 0px; text-decoration: none;">On 10/03/2025 18:51, Andy Goryachev wrote:<br></div><blockquote type="cite" cite="mid:BYAPR10MB30138F9BCE8C7CD533D86221E5D62@BYAPR10MB3013.namprd10.prod.outlook.com" style="font-family: Optima-Regular; font-size: 14px; font-style: normal; font-variant-caps: normal; font-weight: 400; letter-spacing: normal; orphans: auto; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; widows: auto; word-spacing: 0px; -webkit-text-stroke-width: 0px; text-decoration: none;"><div class="WordSection1" style="page: WordSection1;"><div style="margin: 0in; font-size: 10pt; font-family: Aptos, sans-serif;"><span style="font-size: 11pt; font-family: "Iosevka Fixed SS16";">This looks to me like it might be hitting the (native) thread stack size limit.<o:p></o:p></span></div><div style="margin: 0in; font-size: 10pt; font-family: Aptos, sans-serif;"><span style="font-size: 11pt; font-family: "Iosevka Fixed SS16";"><o:p> </o:p></span></div><div style="margin: 0in; font-size: 10pt; font-family: Aptos, sans-serif;"><span style="font-size: 11pt; font-family: "Iosevka Fixed SS16";">c.s.glass.ui.Application::enterNestedEventLoop() even warns about it:<o:p></o:p></span></div><div style="margin: 0in; font-size: 10pt; font-family: Aptos, sans-serif;"><span style="font-size: 11pt; font-family: "Iosevka Fixed SS16";"><o:p> </o:p></span></div><div style="margin: 0in; background: white;"><span style="font-family: "Iosevka Fixed SS16"; color: rgb(255, 38, 0);"> <span class="Apple-converted-space"> </span>* An application may enter several nested loops recursively. There's no</span><span style="font-family: "Iosevka Fixed SS16";"><o:p></o:p></span></div><div style="margin: 0in; background: white;"><span style="font-family: "Iosevka Fixed SS16"; color: rgb(255, 38, 0);"> <span class="Apple-converted-space"> </span>* limit of recursion other than that imposed by the native stack size.</span><span style="font-family: "Iosevka Fixed SS16";"><o:p></o:p></span></div><div style="margin: 0in; font-size: 10pt; font-family: Aptos, sans-serif;"><span style="font-size: 11pt; font-family: "Iosevka Fixed SS16";"><o:p> </o:p></span></div><div style="margin: 0in; font-size: 10pt; font-family: Aptos, sans-serif;"><span style="font-size: 11pt; font-family: "Iosevka Fixed SS16";"><o:p> </o:p></span></div><div style="margin: 0in; font-size: 10pt; font-family: Aptos, sans-serif;"><span style="font-size: 11pt; font-family: "Iosevka Fixed SS16";">-andy<o:p></o:p></span></div><div style="margin: 0in; font-size: 10pt; font-family: Aptos, sans-serif;"><span style="font-size: 11pt; font-family: "Iosevka Fixed SS16";"><o:p> </o:p></span></div><div style="margin: 0in; font-size: 10pt; font-family: Aptos, sans-serif;"><span style="font-size: 11pt; font-family: "Iosevka Fixed SS16";"><o:p> </o:p></span></div><div style="margin: 0in; font-size: 10pt; font-family: Aptos, sans-serif;"><span style="font-size: 11pt; font-family: "Iosevka Fixed SS16";"><o:p> </o:p></span></div><div id="mail-editor-reference-message-container"><div><div><div style="border-width: 1pt medium medium; border-style: solid none none; border-color: rgb(181, 196, 223) currentcolor currentcolor; border-image: none; padding: 3pt 0in 0in;"><p class="MsoNormal" style="margin: 0in 0in 12pt; font-size: 10pt; font-family: Aptos, sans-serif;"><b><span style="font-size: 12pt;">From:<span class="Apple-converted-space"> </span></span></b><span style="font-size: 12pt;">openjfx-dev<span class="Apple-converted-space"> </span><a class="moz-txt-link-rfc2396E" href="mailto:openjfx-dev-retn@openjdk.org"><openjfx-dev-retn@openjdk.org></a><span class="Apple-converted-space"> </span>on behalf of Martin Fox<span class="Apple-converted-space"> </span><a class="moz-txt-link-rfc2396E" href="mailto:martinfox656@gmail.com"><martinfox656@gmail.com></a><br><b>Date:<span class="Apple-converted-space"> </span></b>Monday, March 10, 2025 at 10:10<br><b>To:<span class="Apple-converted-space"> </span></b>Christopher Schnick<span class="Apple-converted-space"> </span><a class="moz-txt-link-rfc2396E" href="mailto:crschnick@xpipe.io"><crschnick@xpipe.io></a><br><b>Cc:<span class="Apple-converted-space"> </span></b>OpenJFX<span class="Apple-converted-space"> </span><a class="moz-txt-link-rfc2396E" href="mailto:openjfx-dev@openjdk.org"><openjfx-dev@openjdk.org></a><br><b>Subject:<span class="Apple-converted-space"> </span></b>Re: JVM crashes on macOS when entering too many nested event loops<o:p></o:p></span></p></div><div><p class="MsoNormal" style="margin: 0in 0in 12pt; font-size: 10pt; font-family: Aptos, sans-serif;"><span style="font-size: 11pt;">Hi Christopher,<br><br>I was able to reproduce this crash. I wrote a small routine that recursively calls itself in a runLater block and then enters a nested event loop. The program crashes when creating loop 254. I’m not sure where that limit comes from so it’s possible that consuming some other system resource could lower it. I couldn’t see any good way to determine how many loops are active by looking at the crash report since it doesn’t show the entire call stack.<br>I did a quick trial on Linux and was able to create a lot more loops (over 600) but then started seeing erratic behavior and errors coming from the Java VM. The behavior was variable unlike on the Mac which always crashes when creating loop 254.<br><br>Martin<br><br>> On Mar 7, 2025, at 6:24</span><span style="font-size: 11pt; font-family: Arial, sans-serif;"> </span><span style="font-size: 11pt;">AM, Christopher Schnick<span class="Apple-converted-space"> </span><a class="moz-txt-link-rfc2396E" href="mailto:crschnick@xpipe.io"><crschnick@xpipe.io></a><span class="Apple-converted-space"> </span>wrote:<br>><span class="Apple-converted-space"> </span><br>> Hello,<br>><span class="Apple-converted-space"> </span><br>> I have attached a JVM fatal error log that seemingly was caused by our JavaFX application entering too many nested event loops, which macOS apparently doesn't like.<br>><span class="Apple-converted-space"> </span><br>> As far as I know, there is no upper limit defined on how often an event loop can be nested, so I think this is a bug that can occur in rare situations.<br>><span class="Apple-converted-space"> </span><br>> Best<br>> Christopher Schnick<hs_err_pid.txt></span></p></div></div></div></div></div></blockquote></div></blockquote></div><br></div></div></body></html>