Reason found for crash, a regression (Re: Does it make sense to raise a showstopper for MacOSX ?

2014-03-25 Thread Rony G. Flatscher (Apache)
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), because
getenv(PATH) returns a null value during startup of the ooRexx interpreter! 
So somewhere the
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).

---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.
http://searchcode.com/codesearch/view/18259454 for 
com.sun.star.script.framework.provider.
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:

 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

 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 https://issues.apache.org/ooo/show_bug.cgi?id=124170, 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 https://issues.apache.org/ooo/show_bug.cgi?id=120359 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 OpenOffice.org 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: dev-unsubscr...@openoffice.apache.org
 For additional commands, e-mail: dev-h...@openoffice.apache.org



Re: Reason found for crash, a regression (Re: Does it make sense to raise a showstopper for MacOSX ?

2014-03-25 Thread Jürgen Schmidt
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), because
 getenv(PATH) returns a null value during startup of the ooRexx interpreter! 
 So somewhere the
 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
code.

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.

Juergen


 
 ---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.
 http://searchcode.com/codesearch/view/18259454 for 
 com.sun.star.script.framework.provider.
 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:

 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

 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 https://issues.apache.org/ooo/show_bug.cgi?id=124170, 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 https://issues.apache.org/ooo/show_bug.cgi?id=120359 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 OpenOffice.org 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: dev-unsubscr...@openoffice.apache.org
 For additional commands, e-mail: dev-h...@openoffice.apache.org

 


-
To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org
For additional commands, e-mail: dev-h...@openoffice.apache.org