Project

General

Profile

Bug #5725

Save dialog's folder drop-down menu crashes kepler in OS X 10.8 w/ 64-bit java 1.6.0_37-b06-434-11M3909

Added by Derik Barseghian almost 7 years ago. Updated over 6 years ago.

Status:
Resolved
Priority:
Normal
Category:
general
Target version:
Start date:
10/29/2012
Due date:
% Done:

0%

Estimated time:
Bugzilla-Id:
5725

Description

On trunk, on Mac OS X 10.8 w/ java -version:
java version "1.6.0_37"
Java(TM) SE Runtime Environment (build 1.6.0_37-b06-434-11M3909)
Java HotSpot(TM) 64-Bit Server VM (build 20.12-b01-434, mixed mode)

clicking on the Save dialog's directory chooser drop down (where it says "MyWorkflows" by default) crashes Kepler with an error, and no stack trace:
[run] Invalid memory access of location 0x7fb90421aea0 rip=0x7fb90421aea0

Jing has 10.8 and the same version of java and it happens to him too.
Dan tried in 10.6, and he didn't have any problems.

MainClass.java (815 Bytes) MainClass.java Derik Barseghian, 11/27/2012 05:53 PM
PtGUIUtilities.diff (1001 Bytes) PtGUIUtilities.diff Derik Barseghian, 12/04/2012 01:33 PM

Related issues

Is duplicate of Kepler - Bug #5890: kepler crash on mac when clinking 'KeplerData' during saving process.Resolved03/12/2013

History

#1 Updated by Derik Barseghian almost 7 years ago

Doesn't happen in:
os X 10.6.8 w/ java 1.6.0_35
win7 w/ java 1.7.0_06
ubuntu w/ java 1.6.0_26

#2 Updated by Derik Barseghian almost 7 years ago

Doesn't happen in 10.8 w/ Kepler 2.3 either, which doesn't include r28887:
--------
Under Mac OS X, use java.awt.FileDialog instead of javax.swing.JFileChooser. This is because Apple applied the native look and feel work to FileDialog, not JFileChooser. See ptolemy.gui.Top for similar work. To switch between the two types of file browsers, set the ptolemy.ptII.useFileDialog property to true or false.
--------

I'm sure I've used the directory chooser drop-down in the Save dialog without getting a jvm crash in 10.8 before, so I suspect the cause is the above change in combination w/ the recent 10.8 java update to 1.6.0_37.

#3 Updated by Christopher Brooks almost 7 years ago

If non-JNI Java code crashes the JVM, then it is typically a bug in the JVM, not the Java code. I suggest searching for

"Invalid memory access of location" FileDialog

Perhaps someone else found a workaround.

Creating a small test case and submitting a bug report to Apple might be worth it.

Sadly, Apple does have an open bug database, so we can't see if other people are
having this problem and submitting bugs.

#4 Updated by Derik Barseghian almost 7 years ago

Yeah. I've been googling, I saw a few people w/ somewhat similar sounding issues -- one filed a bug w/ apple, and another w/ oracle, but no luck yet w/ a workaround.

Kepler's Save dialog makes it to the PtFileChooser.showDialog _fileDialog.show(); call, and gets no further.

_fileDialog.isDisplayable is false. calling pack() on it in the constructor makes it displayable, but this doesn't avoid the crash.

As a test I hacked PtGUIUtilities.useFileDialog() to just return false, so that a JFileChooser is used instead of a FileDialog, and as expected, this works.

The JFileChooser dialog isn't as useful as the apple L&F, but it's a working option to fall back on if we can't resolve the jvm crash.

#5 Updated by Derik Barseghian almost 7 years ago

This doesn't happen in 10.7, with java version 1.6.0_35 or 1.6.0_37.

#6 Updated by Christopher Brooks over 6 years ago

I suggest creating a small test case and submitting a bug report to both Apple and Oracle. See http://www.java2s.com/Code/JavaAPI/java.awtnewFileDialogFrameparentStringtitleintmode.htm
for simple test code that could be used to illustrate the bug.

Apple bugs may be reported at
https://developer.apple.com/bugreporter/

Sadly, Apple does not have a public bug database so it is impossible to search
for preexisting bugs and then vote on them. Instead, you have to file a duplicate bug. What a waste of human effort. Ah, I remember the good old
days of the Sun Java bug database . . .

After reporting the bug, this could be marked as won't fix because it is
Apple-specific.

#7 Updated by Derik Barseghian over 6 years ago

test case does not cause crash

#8 Updated by Derik Barseghian over 6 years ago

I wasn't able to get the crash to occur with a simple test program (attached).

I now notice our crash doesn't always occur -- it's possible to have a save dialog up where the OS X 10.8 directory drop-down chooser works fine. Our crash only appears to occur when the parent Kepler frame gets renamed before the save dialog comes up -- e.g. when you try to save an Unnamed workflow, Kepler first pops up a small Input dialog ("Please enter a name for this workflow:"). You enter a name, and the kepler frame visually appears to get disposed and a new one is created with the new name, and then the save as dialog appears.

My guess is killing the parent of a save dialog as it's launched may be the cause of our invalid memory access crash.

#9 Updated by Charles Cowart over 6 years ago

I have been able to reproduce the error on 10.8 using Java 1.6. The issue appears be related to the AWT. Here is the stack-trace:

Exception Type: EXC_BAD_ACCESS (SIGBUS)
Exception Codes: KERN_PROTECTION_FAILURE at 0x00007fde6844c730

VM Regions Near 0x7fde6844c730:
Java 00000007f4600000-0000000800000000 [186.0M] rw-/rwx SM=PRV
--> MALLOC_TINY 00007fde68400000-00007fde68500000 [ 1024K] rw-/rwx SM=COW
MALLOC_TINY 00007fde68500000-00007fde68700000 [ 2048K] rw-/rwx SM=PRV

Application Specific Information:
Java information:
Exception type: Bus Error (0xa) at pc=7fde6844c730

Java VM: Java HotSpot(TM) 64-Bit Server VM (20.12-b01-434 mixed mode macosx-amd64)

Current thread (7fde6a9fa800): JavaThread "AWT-AppKit" daemon [_thread_in_native, id=2091225472, stack(7fff50dc0000,7fff515c0000)]
Stack: [7fff50dc0000,7fff515c0000]

Java Threads: ( => current thread )
7fde6d989000 JavaThread "Thread-12" [_thread_in_native, id=413585408, stack(11896d000,118a6d000)]
7fde6ca11800 JavaThread "Thread-7" daemon [_thread_blocked, id=500613120, stack(11dc6c000,11dd6c000)]
7fde6dc03800 JavaThread "DestroyJavaVM" [_thread_blocked, id=250687488, stack(10ee13000,10ef13000)]
7fde693dd000 JavaThread "TimerQueue" daemon [_thread_blocked, id=490893312, stack(11d327000,11d427000)]
7fde6ba46000 JavaThread "HSQLDB Connection @18760838" [_thread_in_native, id=486862848, stack(11cf4f000,11d04f000)]
7fde6dc73000 JavaThread "HSQLDB Server @4ad26103" [_thread_in_native, id=485801984, stack(11ce4c000,11cf4c000)]
7fde693dd800 JavaThread "HSQLDB Connection @6f324b17" [_thread_in_native, id=478187520, stack(11c709000,11c809000)]
7fde6ba6e800 JavaThread "HSQLDB Connection @1b4920f8" [_thread_in_native, id=484741120, stack(11cd49000,11ce49000)]
7fde6da60800 JavaThread "HSQLDB Connection @533e846f" [_thread_in_native, id=483680256, stack(11cc46000,11cd46000)]
7fde6cc74800 JavaThread "pool-1-thread-1" [_thread_blocked, id=482619392, stack(11cb43000,11cc43000)]
7fde6cd2c000 JavaThread "HSQLDB Connection @6233549b" [_thread_in_native, id=481558528, stack(11ca40000,11cb40000)]
7fde6d9de800 JavaThread "HSQLDB Timer @49c68e73" daemon [_thread_blocked, id=480497664, stack(11c93d000,11ca3d000)]
7fde6da5b800 JavaThread "HSQLDB Server @29b0d2d0" [_thread_in_native, id=479436800, stack(11c83a000,11c93a000)]
7fde6aac1800 JavaThread "Java2D Disposer" daemon [_thread_blocked, id=474935296, stack(11c3ef000,11c4ef000)]
7fde6ba4a800 JavaThread "AWT-EventQueue-0" [_thread_blocked, id=472158208, stack(11c149000,11c249000)]
7fde6a9fb000 JavaThread "AWT-Shutdown" [_thread_blocked, id=415059968, stack(118ad5000,118bd5000)]
=>7fde6a9fa800 JavaThread "AWT-AppKit" daemon [_thread_in_native, id=2091225472, stack(7fff50dc0000,7fff515c0000)]
7fde6a887000 JavaThread "Low Memory Detector" daemon [_thread_blocked, id=393453568, stack(11763a000,11773a000)]
7fde6a886800 JavaThread "C2 CompilerThread1" daemon [_thread_blocked, id=392392704, stack(117537000,117637000)]
7fde6a885800 JavaThread "C2 CompilerThread0" daemon [_thread_blocked, id=391331840, stack(117434000,117534000)]
7fde6a885000 JavaThread "Signal Dispatcher" daemon [_thread_blocked, id=390270976, stack(117331000,117431000)]
7fde6a804800 JavaThread "Surrogate Locker Thread (Concurrent GC)" daemon [_thread_blocked, id=389210112, stack(11722e000,11732e000)]
7fde6907b800 JavaThread "Finalizer" daemon [_thread_blocked, id=386531328, stack(116fa0000,1170a0000)]
7fde6b80c800 JavaThread "Reference Handler" daemon [_thread_blocked, id=385470464, stack(116e9d000,116f9d000)]
Other Threads:
7fde6b808000 VMThread [stack: 116d9a000,116e9a000] [id=384409600]
7fde6a891000 WatcherThread [stack: 11773d000,11783d000] [id=394514432]

The bug did not appear when I downloaded Java 1.7 from Oracle, installed it, and adjusted my PATH and JAVA_HOME settings.

#10 Updated by Derik Barseghian over 6 years ago

Patch description: Unless ptolemy.ptII.useFileDialog is set true, useFileDialog will now return false if Mac OS X 10.8 and Java 1.6 are detected.

#11 Updated by Derik Barseghian over 6 years ago

In the last Kepler 2.4 call it was suggested I just use JFileChooser when OS X 10.8 and Java 1.6 is detected, since this is the only scenario we've thus far found that causes this JVM crash. Attached is a patch to PtGUIUtilities that does this. Is this ok with you Christopher?

#12 Updated by Derik Barseghian over 6 years ago

The println in the patch might get annoying, we could remove it.

#13 Updated by Christopher Brooks over 6 years ago

I folded the patch in.
To close this bug, someone should check that the crash no longer occurs
under Mac OS 10.8 and JDK 1.6.0_37.

#14 Updated by Derik Barseghian over 6 years ago

Thanks. Verified, closing.

#16 Updated by Redmine Admin over 6 years ago

Original Bugzilla ID was 5725

Also available in: Atom PDF