Re: [Oorexx-devel] RE seeking help for fixing

2017-08-11 Thread Rony G. Flatscher 
Dear P.O.:

On 10.08.2017 23:14, oor...@jonases.se wrote:
> Dear Rony et all,
>
> I continue to run & crash/stall the BSF demo program saving the crash log as 
> I go along. I will
> save and upload new ones as I go along unless told otherwise. I guess it will 
> be more of the same
> most of the time, hopefully you can quickly ignore those. 
>
> It seems that most of the time it is the main thread, the dispatcher that 
> gets crashed by java
> (running, as it seems ooRexx code)
It *always* crashes in ooRexx after an AttachThread() to the Java-GUI-thread (a 
non-ooRexx-thread).

> Is the information below helpful at all or should I stop logging? Is there 
> anything more/else you
> want me to do? I have more information available locally but it is to big for 
> uploading, I can
> search for specific names of routines if you want me to.
For me it is already sufficient. Your MacOSX debug info is much more detailed 
than the
platform-independent hs_error*log (which is great in its own right).

When trying to find the cause of these crashes, unfortunately, my current 
knowledge of the ooRexx
kernel and applying the debugging environments is much too scarce. (Trying to 
peek around the call
stacks and inspecting the different records for literally months has not 
surfaced anything
meaningful, short of knowing the exact inner workings of the ooRexx kernel and 
the assumptions that
play a role there.)

After months of trying to simplify the test cases that are able to cause the 
crashes (without Java
and BSF4ooRexx in the picture) I came up with a few ooRexx-only crashes that I 
have reported and
which code got uploaded to the ooRexx bug database. These programs are 
artificial, but their
complexity was augmented according to the code-paths the BSF4ooRexx 
applications employ. You can
find them in the ooRexx bug-database with this link:
.

So these are the reasons why I have been hoping that those ooRexx developers 
who are acquainted and
experienced with the ooRexx kernel may become able to debug this, if supplying 
test cases that
exhibit the crashes. This has worked out e.g. for 
. So
therefore this call for help for debugging this crash.

---

The actual test application
() 
that uses BSF4ooRexx
has a few benefits:

  * it crashes the same on all operating systems and with all versions of 
ooRexx 5.0beta (32 or 64 bit),
  * the crashes occur far earlier than with the above mentione ooRexx-/C++ only 
test applications,
so hopefully can be easier debugged in the ooRexx kernel with the 
appropriate knowledge that
would allow one to set the break-points at the right locations in the 
ooRexx kernel,
  * it only crashes after ooRexx attached to the Java-GUI-thread, which is a 
thread that is
guaranteed to not have been created by ooRexx.

Best regards,

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

[Oorexx-devel] RE seeking help for fixing

2017-08-10 Thread oor...@jonases.se 
Dear Rony et all,

I continue to run & crash/stall the BSF demo program saving the crash log as I 
go along. I will save and upload new ones as I go along unless told otherwise. 
I guess it will be more of the same most of the time, hopefully you can quickly 
ignore those. 

It seems that most of the time it is the main thread, the dispatcher that gets 
crashed by java (running, as it seems ooRexx code)

Is the information below helpful at all or should I stop logging? Is there 
anything more/else you want me to do? I have more information available locally 
but it is to big for uploading, I can search for specific names of routines if 
you want me to. 

From reading below it seems to point to code in  librexx.5.0.0.dylib or  
libBSF4ooRexx.dylib, does any of the names of the functions/routines ring any 
bells?


Process:   java [2437]
Path:  
/Library/Java/JavaVirtualMachines/jdk1.8.0_101.jdk/Contents/Home/bin/java
Identifier:net.java.openjdk.cmd
Version:   1.0 (1.0)
Code Type: X86-64 (Native)
Parent Process:??? [2436]
Responsible:   java [2437]
User ID:   501

Date/Time: 2017-08-08 16:15:19.498 +0200
OS Version:Mac OS X 10.12.5 (16F73)
Report Version:12
Anonymous UUID:35FB1433-94ED-03C2-AF35-5F90AFF01197

Sleep/Wake UUID:   7602BADF-E6A6-4F1E-82D8-B5ECB6C1E2EE

Time Awake Since Boot: 3900 seconds
Time Since Wake:   850 seconds

System Integrity Protection: enabled

Crashed Thread:0  Dispatch queue: com.apple.main-thread

Exception Type:EXC_BAD_ACCESS (SIGABRT)
Exception Codes:   KERN_INVALID_ADDRESS at 0x0018
Exception Note:EXC_CORPSE_NOTIFY

VM Regions Near 0x18:
--> 
__TEXT 00010bc63000-00010bc75000 [   72K] r-x/rwx 
SM=COW  
/Library/Java/JavaVirtualMachines/jdk1.8.0_101.jdk/Contents/Home/bin/java

Application Specific Information:
abort() called

Thread 0 Crashed:: Dispatch queue: com.apple.main-thread
0   libsystem_kernel.dylib  0x7fffd81d4d42 __pthread_kill + 10
1   libsystem_pthread.dylib 0x7fffd82c2457 pthread_kill + 90
2   libsystem_c.dylib   0x7fffd813a420 abort + 129
3   libjvm.dylib0x00010ca88aeb os::abort(bool) + 25
4   libjvm.dylib0x00010cbaee3e 
VMError::report_and_die() + 2304
5   libjvm.dylib0x00010ca8a716 
JVM_handle_bsd_signal + 1131
6   libjvm.dylib0x00010ca8697b signalHandler(int, 
__siginfo*, void*) + 47
7   libsystem_platform.dylib0x7fffd82b5b3a _sigtramp + 26
8   ??? 0x7fff53f97730 0 + 140734602245936
9   librexx.5.0.0.dylib 0x00012d5c2af6 
DeadObjectPool::findFit(unsigned long, unsigned long*) + 102
10  librexx.5.0.0.dylib 0x00012d5c1708 
NormalSegmentSet::allocateObject(unsigned long) + 312
11  librexx.5.0.0.dylib 0x00012d5d79f2 
MemoryObject::newObject(unsigned long, unsigned long) + 114
12  librexx.5.0.0.dylib 0x00012d524507 new_object(unsigned 
long, unsigned long) + 39
13  librexx.5.0.0.dylib 0x00012d5ac81c 
NativeActivation::operator new(unsigned long) + 28
14  librexx.5.0.0.dylib 0x00012d5ddbb8 
ActivityManager::newNativeActivation(Activity*) + 24
15  librexx.5.0.0.dylib 0x00012d5e2412 
Activity::createNewActivationStack() + 34
16  librexx.5.0.0.dylib 0x00012d5e5627 
Activity::nestAttach() + 39
17  librexx.5.0.0.dylib 0x00012d63d401 
InterpreterInstance::attachThread() + 49
18  librexx.5.0.0.dylib 0x00012d63d3a9 
InterpreterInstance::attachThread(RexxThreadContext_*&) + 25
19  librexx.5.0.0.dylib 0x00012d581e8a AttachThread + 42
20  libBSF4ooRexx.dylib 0x00012d5071bf 
RexxInstance_::AttachThread(RexxThreadContext_**) + 47
21  libBSF4ooRexx.dylib 0x00012d507c40 
Java_org_rexxla_bsf_engines_rexx_RexxAndJava_jniRexxSendMessageToRexxObject + 
432
22  ??? 0x0001175409d4 0 + 4686350804
23  ??? 0x000117531040 0 + 4686286912
24  ??? 0x000117531040 0 + 4686286912
25  ??? 0x000117531040 0 + 4686286912
26  ??? 0x000117531114 0 + 4686287124
27  ??? 0x000117531302 0 + 4686287618
28  ??? 0x000117531040 0 + 4686286912
29  ??? 0x0001175297a7 0 + 4686256039
30  libjvm.dylib0x00010c8ecf06 
JavaCalls::call_helper(JavaValue*, methodHandle*, JavaCallArguments*, Thread*) 
+ 1710
31  libjvm.dylib