Apache OpenOffice (AOO) Bugzilla – Issue 124170
MacOSX 64 CRASH Java awt thread
Last modified: 2014-04-18 11:48:03 UTC
Created attachment 82478 [details] MacOSX DiagnosticFile about the crash. Running the snapshot 4.1.0 MacOSX 64 bit, installing an extension to add the programming language ooRexx (64 bit) using the AOO's Java scripting framework to run a test ooRexx macro, causes a crash in the awt event thread. Using Apple's Java, build: 1.6.0_65-b14-462-11M4609 To duplicate: install the 64-Bit BSF4ooRexx package from <http://sourceforge.net/projects/bsf4oorexx/files/GA/BSF4ooRexx-411.20130714-GA/ooRexx413_WithBSF4ooRexx-413.20130714-x86_64-MacOSX.dmg/download>. Then open AOO, chose "Tools -> Macros -> Organize Macros -> ooRexx". Pick "My Macros", then "Create..." to create the folder "Library1", chose that folder, then "Create..." to create the macro "Macro1.rxo", then chose it and "Edit". This will bring up a simple editor (code drawn from the BeanShell editor window), displaying the Rexx code. Then click "Run..." from the editor window, which will crash AOO. The resulting DiagnosticFiles will be attached to this issue for further inspection. --- P.S.: The same code works in 32-bit on previous versions of MacOSX. The same code in 64-bit works on Linux AOO. P.P.S.: ooRexx in 64-Bit works stand alone using/exploiting the installed Java in 64-bit mode. The AOO Java scripting framework therefore should also be able to load and run ooRexx in 64-bit mode.
Oh, forgot to mention: creating a BeanShell macro and then trying to edit it does not work, i.e. the editor does not come up, however AOO does not crash either. [Running the default BeanShell script works (displaying "Hello World (in BeanShell)", whereas running the default ooRexx script yields a runtime error indicating, that the BSF4ooRexx engine (Java) resp. the library [libBSF4ooRexx.dylib] could not be loaded.] If you need further information/tests please advise.
I tested the Beanshell and can't reproduce the issue. My system is 10.7.5 and I tried Apple Java 1.6.0_65 and Oracle JAva 1.7.0_51. I was able to run the HelloWorld Beanshell example and was able to open the Beanshell editor. Ok I tested with a fresh build trunk version but I am not aware of any fixes in this area.
Hmm, o.k., thank you! I will wait for the next MacOSX snapshot to see whether the problem has gone away. (It puzzles me a little bit that you were able to get the BeanShell editor up and running, whereas I cannot.)
I noticed a problem when I switch from Apple Java to Oracle the dialog show the wrong Java when I open the dialog again. But internally in the javasettings_MacOSX_X86_64.xml file the correct Oracle Java 1.7.x is correct. When using Oracle Java 1.7 I noticed also a little delay until the Beanshell editor comes up.
OK, to counter-test the same code (except for the 64-bit, MacOSX-dependent library which works) on 64-bit Linux, I installed the current AOO 4.1 snapshot (same level as the MacOSX 64 snapshot) on a Ubuntu 12.04 LTS machine (removing LO beforehand), then installed the 64-bit ooRexx support which installs an extension into AOO, if it detects it on the target system. Opening the ooRexx (BeanShell-cloned) editor, run ooRexx scripts from there, but also using "Tools -> Macros -> Run" to run them, all works without a problem. (In the Ubuntu Linux case Oracle Java 1.7.0_51 is used.) Will wait until a new MacOSX 64-bit snapshot gets created (to get at Jürgen's version) and test then again. [Hoping that the problem is gone then. If not, I will have to "swallow the toad" ;) (probably a bad translation from the German proverb "die Kröte schlucken" into English) and start to set-up the debugging infrastructure for MacOSX 64 to trace down the exact location of the problem.]
This might be a related to bug 92926.
Having installed a daily build from Herbert (dated 2014-02-09) and retried installing the ScriptProvider, yielding the same effects as reported. Adding debug statements and using a JOption for making information available via a popup, which yields the following error popup from AOO but does not crash AOO. --------------------- Tools -> Macro -> Run Macro ... Title: OpenOffice Error com.sun.star.uno.RuntimeException[jni_uno_bridge_error] UNO calling Java method invoke: non-UNO exception occurred: java.lang.InternalError: Can't start the AWT because Java was started on the first thread. Make sure StartOnFirstThread is not specified in your application's info.plist or on the command line java stack trace: ... com.sun.star.script.framework.provider.oorexx.ScriptImpl.showErrorMessage(ScriptProviderForooRexx.java:920) ... --------------------- Tools -> Macro -> Organize Macros -> ooRexx ... -> Edit [nothing happens/shows-up] then: Tools -> Macro -> Run Macro ... ... non-UNO exception occurred: java.lang.NoClassDefFoundError: Could not initialize class javax.swing.JOptionPane java.stack.trace: ... in showErrorMessage(...) --------------------- Ad diagnostic reports: while running Herbert's build for MacOSX 64 from 2014-04-09, I uploaded all reports as a zip archive to <http://wi.wu.ac.at/rgf/tmp/aoo/20140211/>. It will live there until not needed anymore. [Please note, the crashes reflect at least three different types. Especially one, where AOO crashed after two minutes, by just having a swriter window open. Unfortuantely, I cannot recreate this problem today anymore.]
Just for the record, dispatching the Rexx script on the wrong thread that inhibits the creation of the Java awt event thread is present in the snapshot revision 1566593 as well (MacOSX 64-bit build, uploaded on 2014-02-12, built on 2014-02-10, downloaded and installed on 2014-02-13).
Maybe a supplement: in order to test this behaviour for yourself, you could download the oxt only from <http://wi.wu.ac.at/rgf/tmp/aoo/20140212/> and install it. All the Java programs of the oxt-package will work, however, the Rexx engine would not be able to be loaded successfully. After installing the oxt, you need to create a default script by restarting AOO and - "Tools -> Macros -> Organize Macros -> ooRexx ...", select "My Macros" and press the "Create..." button, then select "Library1" and press the "Create..." button, which will create a file named "Macro1.rxo" (the default ooRexx macro) and then press the "Run..." button. From this moment on you could also run that macro immediately by choosing "Tools- > Macros -> Run...", select "My Macros", select "Library1", select "Macro1.rxo" and press the "Run" button. In both cases a plain, informal JDialog in the ooRexx scripting framework gets created which causes another popup that contains the error message about not being able to create the awt event thread (indicating that "Run" dispatches the script on the wrong thread?).
Cross-pointing to an older bug report where the thread problem may be the cause of one of the observed problems: <https://issues.apache.org/ooo/show_bug.cgi?id=120359>.
Is this a regression from 4.0.1?
The Java awt problem is a known one and can't be easy fixed. But volunteers are welcome to investigate a solution. One approach can be to move all Java execution (on macos) in a separate process. A lot of work.
The last two days I was able to research this more, using among other things the latest beanshell script provider Java code (from which I inferred the script provider for ooRexx many years ago). The findings: - the crash in the awt thread seems to not be related to the MacOSX AppKit thread; the beanshell provider uses "com.sun.star.script.framework.provider. SwingInvocation" (<http://searchcode.com/codesearch/view/18259454>) which creates a new Java thread and SwingUtilities.invokeLater() to run the code on a separate thread from the AppKit thread (the ooRexx script provider does essentially the same without using the SwingInvocation Java class) - the crash occurs in the awt thread at the point where via the Java native interface (JNI) the ooRexx interpreter gets loaded, which is coded in C++ and which sets itself up using the process environment information, notably the PATH environment variable; here is the stack trace reaching into ooRexx 4.2.0: ------------ cut here ------------ Process: soffice [92432] Path: /Applications/OpenOffice Beta.app/Contents/MacOS/soffice Identifier: org.openoffice.script Version: 4.1.0 (???) Code Type: X86-64 (Native) Parent Process: launchd [254] Responsible: soffice [92432] User ID: 501 Date/Time: 2014-03-24 20:44:16.238 +0100 OS Version: Mac OS X 10.9.2 (13C64) Report Version: 11 Anonymous UUID: E2667C29-B337-0D61-D55C-512C7C88AD32 Sleep/Wake UUID: 5C125262-4B0C-411C-A290-DF7A9D64F65B Crashed Thread: 35 Java: AWT-EventQueue-0 Exception Type: EXC_BAD_ACCESS (SIGSEGV) Exception Codes: KERN_INVALID_ADDRESS at 0x0000000000000000 VM Regions Near 0: --> __TEXT 000000010209e000-000000010209f000 [ 4K] r-x/rwx SM=COW /Applications/OpenOffice Beta.app/Contents/MacOS/soffice Application Specific Information: Java information: Exception type: Bus Error (0xa) at pc=7fff8d3a1732 Java VM: Java HotSpot(TM) 64-Bit Server VM (20.65-b04-462 mixed mode macosx-amd64) ... cut ... Thread 35 Crashed:: Java: AWT-EventQueue-0 0 libsystem_c.dylib 0x00007fff8d3a1732 strlen + 18 1 librexx.4.dylib 0x000000011ee56ea9 SysFileSystem::searchPath(char const*, char const*, char*) + 41 (SysFileSystem.cpp:520) 2 librexx.4.dylib 0x000000011ee56ea9 SysFileSystem::searchPath(char const*, char const*, char*) + 41 (SysFileSystem.cpp:520) 3 librexx.4.dylib 0x000000011ee56dbe SysFileSystem::primitiveSearchName(char const*, char const*, char const*, char*) + 270 (SysFileSystem.cpp:449) 4 librexx.4.dylib 0x000000011ee55ab6 SystemInterpreter::loadImage(char**, unsigned long*) + 102 (FileSystem.cpp:154) 5 librexx.4.dylib 0x000000011ee1de6a RexxMemory::restoreImage() + 58 (RexxMemory.cpp:813) 6 librexx.4.dylib 0x000000011ee1dd97 RexxMemory::initialize(bool) + 839 (RexxMemory.cpp:202) 7 librexx.4.dylib 0x000000011ee5da62 Interpreter::startInterpreter(Interpreter::InterpreterStartupMode) + 66 (Interpreter.cpp:135) 8 librexx.4.dylib 0x000000011ee5de9d Interpreter::createInterpreterInstance(RexxOption*) + 45 (SysSemaphore.hpp:82) 9 librexx.4.dylib 0x000000011ee5de18 Interpreter::createInstance(RexxInstance_*&, RexxThreadContext_*&, RexxOption*) + 24 (Interpreter.cpp:261) 10 librexx.4.dylib 0x000000011edf98d9 RexxCreateInterpreter + 9 (InterpreterAPI.cpp:382) 11 libBSF4ooRexx.dylib 0x0000000109687178 Java_org_rexxla_bsf_engines_rexx_RexxAndJava_jniRexxCreateInterpreterInstance + 2536 12 ??? 0x0000000115741eee 0 + 4654898926 13 ??? 0x00000001157369b3 0 + 4654852531 14 ??? 0x00000001157369b3 0 + 4654852531 15 ??? 0x0000000115736e8d 0 + 4654853773 16 ??? 0x0000000115731438 0 + 4654830648 17 libclient64.dylib 0x0000000114f01ef4 0x114e6b000 + 618228 18 libclient64.dylib 0x0000000114f01cb8 0x114e6b000 + 617656 19 libclient64.dylib 0x0000000114f0d427 JVM_DoPrivileged + 1037 20 libjvmlinkage.dylib 0x000000011557211d JVM_DoPrivileged + 93 ... cut ... ------------ cut here ------------ Asking at the ooRexx developer list the chief developer, Rick McGuire stated (cf. <http://sourceforge.net/p/oorexx/mailman/message/32140007/>): ------------ cut here ------------ Well, the error clearly indicates a null pointer exception, and going back up the call stack, it's clear that this is caused by getenv("PATH") returning a null value for some reason. Rick ------------ cut here ------------ If anyone is interested to check out that code, here is the URL to the release 4.2.0 version that I used: <http://sourceforge.net/p/oorexx/code-0/HEAD/tree/main/releases/4.2.0/trunk/>. So: the crash is not caused by the awt-thread running on the AppKit thread. (Using SwingInvocation makes sure that a non-AppKit-thread is used to satisfy Java on MacOSX if awt is needed.) Rather the problem seems to be that on the MacOSX getnv("PATH") returns a null value for unknown reasons. As this has worked in the past (in the OOo 3.x days) I would assume this to be a regression. As a result, I would like to invalidate this issue and create a new issue.
Here is the follow-up issue: <https://issues.apache.org/ooo/show_bug.cgi?id=124509>.
Just a last remark: the crash occurs because the environment variable PATH is not set and ooRexx crashes as a result (it needs PATH to initialize itself in full). Using the ooRexx (Java) editor's "Run" will use SwingUtilities.invokeLater(aRunnable) on a new Java thread so there would be now problem with regards of running the ooRexx script on the AppKit thread. --- HOWEVER, there is still a problem that AOO dispatches Rexx scripts (Tools -> Macros -> Run and then choosing an ooRexx script) on the awt thread. This will yield the error: "com.sun.star.uno.RuntimeException[jni_uno bridge error] UNO calling Java method invoke: non-UNO exception occurred: java.lang.InternalError: Can't start the AWT because Java was started on the first thread. Make sure StartOnFirstThread is not specified in your application's Info.plist or on the command line" So this should be still something to solve. Should I create a new issue for that or is it o.k. to leave it with this issue?
Looked a little bit closer at the BeanShell macro to test the scripting environment and it turns out that it can execute in "headless" mode as it is not instantiating anything related to awt. However, the following simple BeanShell macro exhibits exactly the reported behaviour: --------------------- cut here --------------------- JOptionPane.showMessageDialog(null, "Testing awt-support, BeanShellScript is done!"); return 0 --------------------- cut here --------------------- After saving the above BeanShell macro, one can run it successfully from the editor, as the editor is running on a separate Java thread and invocation uses SwingUtilities.invokeLater(), such that the invocation is carried out on the Java awt thread. Interestingly, if running scripts from the editor, then afterwards running scripts directly via "Tools -> Macros -> Run Macro ..." may run as well (however, sometimes they cause hangs). Hence it is important to quit AOO before running the above macro via "Tools -> Macros -> Run Macro ...", such that on the next start Java is at its "initial", well defined state. Then you will get the error popup informing the user about not being able to execute the program because of the AWT problem. Repeating "Run Macro ..." again may yield the popup window, however the user interface hangs such that one must do a "Force Quit" of AOO. As if the Java environment is out of order somehow (obviously linked to event handling on MacOSX). --- Some solutions (in other contexts) are hinted in <http://stackoverflow.com/questions/14661249/java-jni-creating-a-swing-window-using-jni-from-c>, which points to <http://stackoverflow.com/questions/8750690/osx-javavm-awt-swing-and-possibly-a-deadlock/14859179>. Maybe they hint at feasible resolutions that do not incur "too much work" for MacOSX? ;)