openoffice-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jürgen Schmidt <>
Subject Re: Reason found for crash, a regression (Re: Does it make sense to raise a showstopper for MacOSX ?
Date Tue, 25 Mar 2014 12:31:43 GMT
On 3/25/14 12:51 PM, Rony G. Flatscher (Apache) wrote:
> Hi Jürgen,
> in the past two days I traced down the crash and I think I found the reason, which looks
like a
> regression to me (worked on OOo 2.x and OOo 3.x): when the ooRexx interpreter is loaded
via JNI it
> needs to get its pieces together and relies on information from the process environment.
> This particular crash occurs on MacOSX only (works flawlessly on 32/64 Linux and Windows),
> getenv("PATH") returns a null value during startup of the ooRexx interpreter! So somewhere
> environment is not properly set up for the scripting framework, if e.g. PATH is not accessible.
> Thought I report my findings ASAP with the latest MacOSX beta, will update the issue
later this
> evening and create an issue requesting a showstopper flag (have to leave).

crashing when PATH is null for whatever reason is strange, where is his

But to be honest this sounds not really like a showstopper to me but if
somebody has a fix in time we can take it for 4.1.


> ---rony
> P.S.: It was just a coincidence that the Java thread where the crash occurs is at the
same time the
> awt thread. That thread is not in jeopardy with the MacOSX AppKit thread. Cf.
> <> for "
> SwingInvocation" that gets used in beanshell.
> On 26.02.2014 15:38, Jürgen Schmidt wrote:
>> Hi Ronny,
>> the problem is not new as far as I know and not easy to fix. Both the
>> office and the JVM requires to run their event loop in the main thread
>> and this conflicts on MacOS.
>> A solution can be potentially to start the JVM in a separate process and
>> bridge the communication via UNO.
>> But I don't see the chance that it get fixed for AOO 4.1 or in the near
>> future.
>> Any usage of awt in macros or extensions on Mac will cause problems and
>> is not recommended. And again this problem is not new and exists since
>> some time.
>> It is correct that it worked in the past and I don't know when the
>> problem was introduced and which change triggered it. But I know that
>> exists since several years and is not easy to fix.
>> Juergen
>> On 2/26/14 3:12 PM, Rony G. Flatscher (Apache) wrote:
>>> Hi there,
>>> it seems that dispatching scripts via AOO's Java scripting framework is done
using the wrong thread
>>> on MacOSX.
>>> This reasoning stems from observing the Java runtime error to be caused e.g.
when using a JDialog to
>>> popup reporting the following 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
>>> This problem is also present in Herbert's latest drop.
>>> This effectively inhibits dispatching any scripts from within AOO on MacOSX,
which works fine on
>>> Windows and Linux otherwise (in 32- and the latter in addition in 64-bit).
>>> As the code for making ooRexx available was copied from the BeanShell's Java
scripting framework
>>> implementation and works on all other platforms flawlessly, this seems to be
a serious error on
>>> MacOSX, and therefore a showstopper, IMHO.
>>> [The code gets dispatched by AOO and on its supplied thread.]
>>> However and interestingly, there seems to be no problem with BeanShell and JavaScript,
which is
>>> surprising to me. Not sure why they execute properly on MacOSX, but that observation
is also the
>>> reason why I prefer to ask first, before setting the showstopper flag on bug
124170 (see below).
>>> There are two bug issues that document this problem:
>>>   * Bug <>, Comment
# 9: explains where to find
>>>     the (basically a pure Java-) oxt (a debug version using JDialog) and how
to get the Java error
>>>     on MacOSX.
>>>   * Bug <> is probably
related to the same
>>>     reason (in the part describing problems dispatching scripts and some sort
of work around that
>>>     more or less worked on the prior 32-bit version).
>>> ---
>>> It might be interesting to note, that in times (32-bit OOo) it
used to work on
>>> MacOSX. I am not aware of any changes in the scripting framework that could cause
this behaviour.
>>> ---rony
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail:
>> For additional commands, e-mail:

To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message