Crashes in Java_sun_lwawt_macosx_LWCToolkit_stopAWTRunLoop (called with NULL argument)

[Anthony Petrov]

Wow, that's a good analysis of the problem, Hendrik. Thank you.

Would you like to investigate this a bit deeper and come up with a fix 
for JDK? We would gladly accept a contribution from you. You can find 
more information on how to get started here: 
http://openjdk.java.net/contribute/ Also, the patch would need to be 
reviewed on the awt-dev@ mailing list.

Otherwise, I could only add those comments to the bug report and move it 
to the JDK project in JIRA so that it becomes visible, but I'm afraid we 
won't be able to do much on this issue any time soon because we don't 
have a test app that we could use to reproduce the crash and then 
confirm whether we've fixed anything or not.

--
best regards,
Anthony

On 8/29/2014 4:45 PM, Hendrik Schreiber wrote:
> On Aug 28, 2014, at 20:16, Anthony Petrov <anthony.petrov at oracle.com> wrote:
>
>> JI-9014527 was closed as Incomplete "Not enough information.", supposedly because there's not a reproducible test case and instructions to reproduce the issue.
>
> That is correct. I erroneously assumed that people reviewing bug reports would be interested in crashes, and their crashlogs, even if they do not contain step-by-step instructions on how to reproduce the issue.
>
>> If you come up with a simple test that crashes easily, we can re-open that bug.
>
> I wish I could.
>
>> BTW, from the full stack trace in the bug report I can see you're running some accessibility software on your system because the crash happens during an a11y callback. This may be a contributing factor to the crash. You will need to test with and without a11y on, and also perhaps try another assistive technology (e.g. the built-in VoiceOver vs. a third-party software) to see if this changes anything.
>
> Digging into the source code it becomes clear that
>
> Java_sun_lwawt_macosx_LWCToolkit_stopAWTRunLoop is only called from
>
>   - sun.lwawt.macosx.CToolkitThreadBlockedHandler and
>   - sun.lwawt.macosx.LWCToolkit
>
>
> The call from LWCToolkit is coded defensively, i.e. it has a 0-check:
>
> if (mediator != 0) {
>      stopAWTRunLoop(mediator);
> }
>
> Therefore it cannot lead to the failure described in http://www.beatunes.com/download/stopAWTRunLoop.crash
>
> The call from CToolkitThreadBlockedHandler is NOT coded defensively. To the contrary, it relies on the implicit contract, that the  exit() method is called at most once after the enter() method is called:
>
>      public void exit() {
>          if (!isOwned()) {
>              throw new IllegalMonitorStateException();
>          }
>          LWCToolkit.stopAWTRunLoop(awtRunLoopMediator);
>          awtRunLoopMediator = 0;
>      }
>
> It might be a good idea to simply guard against other classes using enter()/exit() in unintended ways by rewriting it defensively like this:
>
>      public void enter() {
>          if (!isOwned()) {
>              throw new IllegalMonitorStateException();
>          }
>          if (awtRunLoopMediator != 0) {
>              throw new IllegalStateException("Call exit() first.");
>          }
>          awtRunLoopMediator = LWCToolkit.createAWTRunLoopMediator();
>          unlock();
>          LWCToolkit.doAWTRunLoop(awtRunLoopMediator, processEvents);
>          lock();
>      }
>
>      public void exit() {
>          if (!isOwned()) {
>              throw new IllegalMonitorStateException();
>          }
>          if (awtRunLoopMediator != 0) {
>              LWCToolkit.stopAWTRunLoop(awtRunLoopMediator);
>              awtRunLoopMediator = 0;
>          }
>      }
>
> That said, enter() and exit() are only called from one place, sun.awt.datatransfer.DataTransferer#convertData(...).
> My guess is, that for some reason getToolkitThreadBlockedHandler().exit(); is either called multiple times or LWCToolkit.createAWTRunLoopMediator() in CToolkitThreadBlockedHandler#enter() returns 0 for whatever reason.
>
> Frankly, I don't quite understand how it can happen that the dataConverter Runnable in DataTransferer#convertData(...) is executed multiple times, but clearly it is a problem, as the code tries to guard against it. It does not do so in a threadsafe way though.
>
> Anyhow.
>
> I would appreciate it, if you considered reviewing both my suggestion for improving sun.lwawt.macosx.CToolkitThreadBlockedHandler and perhaps the code in sun.awt.datatransfer.DataTransferer to improve the stability of the Java VM on OS X.
>
> Thank you.
>
> -hendrik
>