Issue 124170 - MacOSX 64 CRASH Java awt thread
Summary: MacOSX 64 CRASH Java awt thread
Alias: None
Product: General
Classification: Code
Component: scripting (show other issues)
Version: 4.1.0-dev
Hardware: All OS X 10.9
: P3 Major (vote)
Target Milestone: ---
Assignee: AOO issues mailing list
QA Contact:
Keywords: crash
Depends on:
Reported: 2014-02-02 17:58 UTC by rony
Modified: 2014-04-18 11:48 UTC (History)
5 users (show)

See Also:
Issue Type: DEFECT
Latest Confirmation in: ---
Developer Difficulty: ---

MacOSX DiagnosticFile about the crash. (62.71 KB, application/x-zip-compressed)
2014-02-02 17:58 UTC, rony
no flags Details

Note You need to log in before you can comment on or make changes to this issue.
Description rony 2014-02-02 17:58:36 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 <>. 

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.


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.
Comment 1 rony 2014-02-02 18:05:03 UTC
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.
Comment 2 jsc 2014-02-04 12:02:39 UTC
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.
Comment 3 rony 2014-02-04 12:09:15 UTC
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.)
Comment 4 jsc 2014-02-04 12:14:17 UTC
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.
Comment 5 rony 2014-02-04 14:17:53 UTC
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.]
Comment 6 2014-02-11 13:59:02 UTC
This might be a related to bug 92926.
Comment 7 rony 2014-02-11 14:27:59 UTC
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[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:


   Tools -> Macro -> Organize Macros -> ooRexx ... -> Edit [nothing happens/shows-up]


   Tools -> Macro -> Run Macro ...

... non-UNO exception occurred:
java.lang.NoClassDefFoundError: Could not initialize class

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 <>. 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.]
Comment 8 rony 2014-02-13 15:14:18 UTC
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).
Comment 9 rony 2014-02-17 13:34:37 UTC
Maybe a supplement: in order to test this behaviour for yourself, you could download the oxt only from <> 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?).
Comment 10 rony 2014-02-18 15:25:24 UTC
Cross-pointing to an older bug report where the thread problem may be the cause of one of the observed problems: <>.
Comment 11 Rainer Bielefeld 2014-03-25 05:32:38 UTC
Is this a regression from 4.0.1?
Comment 12 jsc 2014-03-25 07:59:26 UTC
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.
Comment 13 rony 2014-03-25 15:00:37 UTC
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 "
SwingInvocation" (<>) 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
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 Codes: KERN_INVALID_ADDRESS at 0x0000000000000000

VM Regions Near 0:
    __TEXT                 000000010209e000-000000010209f000 [    4K] r-x/rwx SM=COW  /Applications/OpenOffice

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. <>):

------------ 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. 

------------ 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: <>.

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.
Comment 14 rony 2014-03-25 15:12:24 UTC
Here is the follow-up issue: <>.
Comment 15 rony 2014-03-27 18:33:51 UTC
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:

"[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?
Comment 16 rony 2014-04-18 11:48:03 UTC
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 <>, which points to <>. 

Maybe they hint at feasible resolutions that do not incur "too much work" for MacOSX?