Currentyl, as you know there are sometimes crashes if using Rexx via native
code from different
threads, some not created by Rexx but by Java/native code.
A student has been developing a portable GUI version of rexxtry.rex using
JavaFX. He added syntax
highlighting (using the RichTextFX control from <http://fxmisc.github.io/> and
the
ooRexx-Java-parser from the ooRexxPlugin4IntelliJ from
<https://sourceforge.net/projects/bsf4oorexx/files/Sandbox/aseik/ooRexxIDEA/beta/1.0.3.1/>)
and now
the (great!) project crashes when the syntax highlighting takes place. The way
RichTextFX allows for
syntax highlighting is by means of Java 8 streams and lambda functions
(implemented in ooRexx) using
an executor
(<https://docs.oracle.com/javase/7/docs/api/java/util/concurrent/ExecutorService.html>)
and a JavaFX Task
(https://docs.oracle.com/javase/8/javafx/api/javafx/concurrent/Task.html).
The Rexx code implements in essence the strategy depicted in
<https://github.com/TomasMikula/RichTextFX/blob/master/richtextfx-demos/src/main/java/org/fxmisc/richtext/demo/JavaKeywordsAsync.java>,
just in pure Rexx.
The point here is that there are intensive interactions (cross-calls) between
Java and ooRexx, many
on threads that are not created by ooRexx but by Java. The intensive execution
("flurry" of
cross-calls) that takes place in syntax highlighting may be distributed among
different Java
threads, so thread switchings may take place while executing. It is in this
context that the crashes
appear and they all have to do with a call from Java to Rexx, invoking a
SendMessageArray() which in
the case of a crash leads to a NormalSegmentSet::handleAllocationFailure and
eventually crashes at
ObjectHeader::isObjectMarked.
---
Assuming that thread switching may play a role, I stumbled over the following
(professional MS cl
version 14.00.24210.0) compilation warning of 32-bit ooRexx on Windows (the
unix version uses
pragmas to inhibit warnings):
[ 6%] Building CXX object
CMakeFiles/rexxapi.dir/common/platform/windows/SysThread.cpp.obj
SysThread.cpp
g:\oorexx.tmp\oorexxsvn\main\trunk\common\platform\windows\systhread.cpp(112) :
warning C4172: returning address of local variable or temporary: temp
Looking up the code in window\SysThread.cpp (THREAD_STACK_SIZE is currently
defined as "1024*512" in
window\SysThread.hpp; on unix/SysThread.hpp, interestingly, it is set to
"1024*96"):
char *SysThread::getStackBase()
/******************************************************************************/
/* Function: Return a pointer to the current stack base
*/
/******************************************************************************/
{
int32_t temp;
return ((char *)(&temp)) - THREAD_STACK_SIZE;
}
Could it be that getStackBase() may return different values if executed
multiple times creating
side-effects that could lead to mispointers/misindices ("temp" gets created on
the stack each time
getStackBase() gets called and non-Rexx-code may use the thread's stack as
well)?
---rony
------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
_______________________________________________
Oorexx-devel mailing list
Oorexx-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/oorexx-devel
