chromiumembedded
Fix thread race conditions
Original report by me.
There are a number of issues that appear to be race conditions between the Java AWT thread and the CEF UI thread. We should come up with a common strategy to address this (synchronization, moving execution to a particular thread, etc).
This issue mostly surfaces as crashes during JCEF initialization, browser reparenting, and JCEF shutdown. For example, from issue #369:
- Tests > Reparent
- Click Reparent <
- Close new window
- Crash with “Check failed: !IsCefShutdown(). Object reference incorrectly held at CefShutdown”
The crash from step 4 also occurs occasionally (but not consistently) when shutting down without reparenting the browser first. See this comment where adding a delay makes it less likely.
Issue #356 and issue #380 include PRs to fix related issues on Linux and Mac respectively. Issue #357 is a related issue in JOGL with Mac OSR.
Original comment by Andrei Pivkine (Bitbucket: andreiPiv, GitHub: andreiPiv).
Would love to see this fixed on Windows too :grin:
The two issues I cannot solve are intermittent crashes on calling N_Initialize and N_Shutdown. Usually these are only reproduced in automated testing. (I haven’t tried the absolute latest patches though)
Original comment by Andrei Pivkine (Bitbucket: andreiPiv, GitHub: andreiPiv).
does https://bitbucket.org/chromiumembedded/cef/issues/2668/multi-threaded-message-loop-crashes-again fix the issue #349? (The initialization)
Same problem here, but specifically on Linux. I have a Compose desktop app that uses JCEF for an internal browser. On Linux specifically, when I try to initialize, my app will crash with a segmentation fault seemingly randomly. It happens more often than not but will sometimes work indicating that this is likely a race condition. From debugging I can pretty confidently say it happens in java event dispatch thread
