Re: [Oorexx-devel] [oorexx:bugs] #1785 ooRexx-5.0.0-12302.macOS.arm64.x86_64.dmg misbehaviour

[P.O. Jonsson]

Hi!

This is what I did in the test, but apparently my mail bounced? I sent out a 
test to you and the user Drougge but is came back. So I am going ahead and do 
this change for all platforms for rexx.img and for !_Win32, i.e. all 
non-Windows platforms.

My problem is that my own machines are on High Sierra and Mojave so I cannot do 
the „Fat“ binaries on any other machine than the build machine (and, possibly 
my Laptop if I upgrade it to Big Sur) but High Sierra is SO much more 
relaxed to work with. I don’t need the policeman in Big Sur & CO lookin over my 
shoulder.

Stay Tuned

Hälsningar/Regards/Grüsse,
P.O. Jonsson
oor...@jonases.se



> Am 22.11.2021 um 23:19 schrieb Enrico Sorichetti via Oorexx-devel 
> :
> 
> 
> 
>> On 22 Nov 2021, at 21:55, P.O. Jonsson > > wrote:
>> 
>> Is there a disadvantage to add (OWNER_WRITE) for all platforms? If so I will 
>> branch the 2nd part of this build step, but I would prefer to KIS. Same for 
>> the man page entries.
> 
> 
> 
> Adding OWNER WRITE is mandatory fora a proper sudo-less setup
> Without  it sudo becomes necessary for the uninstall  
> 
> By the way the man pages have the same problems is enough to add  OWNER WRITE 
> to them also
> 
> Best regards 
> Enrico 
> 
> 
> 
> 
> ___
> Oorexx-devel mailing list
> Oorexx-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/oorexx-devel

___
Oorexx-devel mailing list
Oorexx-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/oorexx-devel

Re: [Oorexx-devel] [oorexx:bugs] #1785 ooRexx-5.0.0-12302.macOS.arm64.x86_64.dmg misbehaviour

[Enrico Sorichetti via Oorexx-devel]

> On 22 Nov 2021, at 21:55, P.O. Jonsson  wrote:
> 
> Is there a disadvantage to add (OWNER_WRITE) for all platforms? If so I will 
> branch the 2nd part of this build step, but I would prefer to KIS. Same for 
> the man page entries.



Adding OWNER WRITE is mandatory fora a proper sudo-less setup
Without  it sudo becomes necessary for the uninstall  

By the way the man pages have the same problems is enough to add  OWNER WRITE 
to them also

Best regards 
Enrico 




___
Oorexx-devel mailing list
Oorexx-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/oorexx-devel

[Oorexx-devel] Fwd: [oorexx:bugs] #1785 ooRexx-5.0.0-12302.macOS.arm64.x86_64.dmg misbehaviour

[P.O. Jonsson]

Dear developers,

I am addressing this problem, specific to Apple. I can change the permissions 
in a post-build step but I think the right place to do this is in 
CMakeLists.txt. In 

# Build the rexx.img file
add_custom_command(OUTPUT ${ORX_IMAGE_OUTPUT_LOCATION}/rexx.img
   COMMAND $ 
${ORX_IMAGE_OUTPUT_LOCATION}/rexx.img
   DEPENDS rexximage rxapi ${image_class_files} 
${platform_rexx_img_depends}
   WORKING_DIRECTORY ${CMAKE_RUNTIME_OUTPUT_DIRECTORY})

add_custom_target(rexx_img ALL DEPENDS ${ORX_IMAGE_OUTPUT_LOCATION}/rexx.img)
install(PROGRAMS ${ORX_IMAGE_OUTPUT_LOCATION}/rexx.img COMPONENT Core 
DESTINATION ${INSTALL_LIB_DIR} PERMISSIONS OWNER_EXECUTE GROUP_EXECUTE 
WORLD_EXECUTE OWNER_READ GROUP_READ WORLD_READ)

Is there a disadvantage to add (OWNER_WRITE) for all platforms? If so I will 
branch the 2nd part of this build step, but I would prefer to KIS. Same for the 
man page entries.

Hälsningar/Regards/Grüsse,
P.O. Jonsson
oor...@jonases.se



> Anfang der weitergeleiteten Nachricht:
> 
> Von: "Iggy Drougge" 
> Betreff: [oorexx:bugs] #1785 ooRexx-5.0.0-12302.macOS.arm64.x86_64.dmg 
> misbehaviour
> Datum: 22. November 2021 um 15:24:25 MEZ
> An: "[oorexx:bugs] " <1...@bugs.oorexx.p.re.sourceforge.net>
> Antwort an: "[oorexx:bugs] " <1...@bugs.oorexx.p.re.sourceforge.net>
> 
> Can confirm that this issue persists in 
> `ooRexx-5.0.0-12313.macOS.arm64.x86_64` on MacOS Mojave.
> 
> 
> ---
> 
> ** [bugs:#1785] ooRexx-5.0.0-12302.macOS.arm64.x86_64.dmg misbehaviour**
> 
> **Status:** open
> **Group:** None
> **Created:** Sun Oct 31, 2021 08:24 PM UTC by Enrico  
> **Last Updated:** Tue Nov 02, 2021 03:17 PM UTC
> **Owner:** nobody
> 
> 
> after the drag and drop issuing the command 
> `/Applications/ooRexx5/rexx -v`
> 
> gets a flower box with 
> `“rexx” cannot be opened because the developer cannot be verified.`
> 
> it should be documented  that after the drag and drop  
> the `com.apple.quarantine` extended attribute should be removed with the 
> sequence 
> `cd /Applications/ooRexx5`
> `xattr -d -r com.apple.quarantine * `
> 
> unfortunatly the  command  fails because a few files were installed  without 
> the `write` permission bit
> `lib/rexx.img`
> `share/man/man1/rexx.1.gz`
> `share/man/man1/rexxc.1.gz`
> `share/man/man1/rxqueue.1.gz`
> `share/man/man1/rxsubcom.1.gz`
> 
> 
> e
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> ---
> 
> Sent from sourceforge.net because you indicated interest in 
> 
> 
> 
> 
> To unsubscribe from further messages, please visit 
> 

___
Oorexx-devel mailing list
Oorexx-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/oorexx-devel

Re: [Oorexx-devel] A crash in SysInterpreterInstance() always at the same number of invocations

[Rony G. Flatscher]

On 22.11.2021 18:11, Rick McGuire wrote:
> I'm not sure what in that particular line could cause a crash, but it might 
> be because we do the
> reinitialization every time an interpreter instance is created. Those are 
> thing that should only
> be one once per process, so I rearranged the code a bit.

thank you, that fixes it!

---rony

>
> On Mon, Nov 22, 2021 at 11:37 AM Rony G. Flatscher  > wrote:
>
> On 22.11.2021 17:15, Michael Lueck wrote:
> > Greetings ooRexx'ers,
> >
> > Rony G. Flatscher wrote:
> >> Just filed a bug (with the code attached) at 
>  >.
> >
> >
> > So I read through that thread... seems possibly Rick spotted the defect 
> in Rony's code, and
> > therefor cleared ooRexx of any defect in this area?
>
> No.
>
> My test code was without Java trying to mimic what happens in the Java 
> based web server (so
> the code
> was created ad hoc from scratch, is relatively complex and I have 
> permutated it over the weeks and
> in one scenario got a crash that I reported with the code). The 
> termination of Rexx interpreter
> instances (rii) occurred in a native method but in the context of the 
> very same rii, which
> caused in
> this scenario the crash (due to exhausted system resources).
>
> The true ooRexx crash occurs in a different scenario running in a Tomcat 
> (Java) process. Today I
> became able to create mini dumps on the Java web server in case a crash 
> occurs. This is what I
> reported today (the error message is: "Unhandled exception at 0x634D8CE1 
> (rexx.dll) in
> hs_err_pid1628.mdmp: 0xC005: Access violation reading location 
> 0x." ) in the e-mail
> subject changed to "MSVS MiniDump created, more concrete infos ...".
>
> ---rony
>

___
Oorexx-devel mailing list
Oorexx-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/oorexx-devel

Re: [Oorexx-devel] A crash in SysInterpreterInstance() always at the same number of invocations

[Rick McGuire]

I'm not sure what in that particular line could cause a crash, but it might
be because we do the reinitialization every time an interpreter instance is
created. Those are thing that should only be one once per process, so I
rearranged the code a bit.

Rick

On Mon, Nov 22, 2021 at 11:37 AM Rony G. Flatscher 
wrote:

> On 22.11.2021 17:15, Michael Lueck wrote:
> > Greetings ooRexx'ers,
> >
> > Rony G. Flatscher wrote:
> >> Just filed a bug (with the code attached) at <
> https://sourceforge.net/p/oorexx/bugs/1789/>.
> >
> >
> > So I read through that thread... seems possibly Rick spotted the defect
> in Rony's code, and
> > therefor cleared ooRexx of any defect in this area?
>
> No.
>
> My test code was without Java trying to mimic what happens in the Java
> based web server (so the code
> was created ad hoc from scratch, is relatively complex and I have
> permutated it over the weeks and
> in one scenario got a crash that I reported with the code). The
> termination of Rexx interpreter
> instances (rii) occurred in a native method but in the context of the very
> same rii, which caused in
> this scenario the crash (due to exhausted system resources).
>
> The true ooRexx crash occurs in a different scenario running in a Tomcat
> (Java) process. Today I
> became able to create mini dumps on the Java web server in case a crash
> occurs. This is what I
> reported today (the error message is: "Unhandled exception at 0x634D8CE1
> (rexx.dll) in
> hs_err_pid1628.mdmp: 0xC005: Access violation reading location
> 0x." ) in the e-mail
> subject changed to "MSVS MiniDump created, more concrete infos ...".
>
> ---rony
>
>
>
> ___
> Oorexx-devel mailing list
> Oorexx-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/oorexx-devel
>


instance.patch
Description: Binary data
___
Oorexx-devel mailing list
Oorexx-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/oorexx-devel

Re: [Oorexx-devel] A crash in SysInterpreterInstance() always at the same number of invocations

[Rony G. Flatscher]

On 22.11.2021 17:15, Michael Lueck wrote:
> Greetings ooRexx'ers,
>
> Rony G. Flatscher wrote:
>> Just filed a bug (with the code attached) at 
>> .
>
>
> So I read through that thread... seems possibly Rick spotted the defect in 
> Rony's code, and
> therefor cleared ooRexx of any defect in this area?

No.

My test code was without Java trying to mimic what happens in the Java based 
web server (so the code
was created ad hoc from scratch, is relatively complex and I have permutated it 
over the weeks and
in one scenario got a crash that I reported with the code). The termination of 
Rexx interpreter
instances (rii) occurred in a native method but in the context of the very same 
rii, which caused in
this scenario the crash (due to exhausted system resources).

The true ooRexx crash occurs in a different scenario running in a Tomcat (Java) 
process. Today I
became able to create mini dumps on the Java web server in case a crash occurs. 
This is what I
reported today (the error message is: "Unhandled exception at 0x634D8CE1 
(rexx.dll) in
hs_err_pid1628.mdmp: 0xC005: Access violation reading location 0x." 
) in the e-mail
subject changed to "MSVS MiniDump created, more concrete infos ...".

---rony



___
Oorexx-devel mailing list
Oorexx-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/oorexx-devel

Re: [Oorexx-devel] A crash in SysInterpreterInstance() always at the same number of invocations

[Michael Lueck]

Greetings ooRexx'ers,

Rony G. Flatscher wrote:

Just filed a bug (with the code attached) at 
.



So I read through that thread... seems possibly Rick spotted the defect in 
Rony's code, and therefor cleared ooRexx of any defect in this area?

I am thankful,

--
Michael Lueck
Lueck Data Systems
http://www.lueckdatasystems.com/


___
Oorexx-devel mailing list
Oorexx-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/oorexx-devel

[Oorexx-devel] MSVS MiniDump created, more concrete infos ... (Re: A crash in SysInterpreterInstance() always at the same number of invocations

[Rony G. Flatscher]

As my sample was not valid (terminating the Rexx instance on the Rexx instance 
itself would not
allow termination, hence eating up all available memory on each new Rexx 
interpreter instance until
no more memory available and therefore crashing), I have been trying to come up 
with variants to
provoke that observed crash to no avail.

Have researched the Java debug possibilities as the crash in the Java based web 
server would not
allow MSVS to attach to the process as Java would handle it already by creating 
a hs_error*.log file.

However, on Java it is possible to create a mini dump by starting the Java VM 
with the start up
switch "|-XX:+CreateMinidumpOnCrash|" (supposedly "CreateMinidumpOnCrash" was 
Windows only and
starting with Java 9 it got changed to "CreateCoredumpOnCrash", but as of Java 
17 is still
functional). It gets created in the same directory as the hs_error*log file and 
carries the same
name but with the "mdmp" extension.

Having created ooRexx r12308 with "relWithDebInfos" this mini dump can be 
loaded with MS
VisualStudio and positions on the crashing source line # 160 in 
SysInterpreterInstance.cpp :

... cut ...

    if ((_fileno(stderr) < 0) && 
(GetFileType(GetStdHandle(STD_ERROR_HANDLE)) != FILE_TYPE_UNKNOWN))
{
**stderr = 
*_fdopen(_open_osfhandle((intptr_t)GetStdHandle(STD_ERROR_HANDLE),_O_APPEND), 
"a");*
}
// enable trapping for CTRL_C exceptions

... cut ...

Here the CallStack:

>   rexx.dll!SysInterpreterInstance::initialize(InterpreterInstance * 
i=0x19d9f9a8, RexxOption * options=0x15e04558) Line 160   C++
rexx.dll!InterpreterInstance::initialize(Activity * 
activity=0x19d9f640, RexxOption * options=0x15e04558) Line 161  C++
rexx.dll!Interpreter::createInterpreterInstance(RexxOption * 
options=0x15e04558) Line 345   C++
rexx.dll!Interpreter::createInstance(RexxInstance_ * & 
instance=0x, RexxThreadContext_ * & threadContext=0x1894ef28, 
RexxOption * options=0x15e04558) Line 284  C++
rexx.dll!RexxCreateInterpreter(RexxInstance_ * * instance=0x1894ef20, 
RexxThreadContext_ * * context=0x1894eee8, RexxOption * options=0x15e04558) 
Line 395  C++
BSF4ooRexx.dll!638986d5()   Unknown
[Frames below may be incorrect and/or missing, no symbols loaded for 
BSF4ooRexx.dll]
0162873c()  Unknown

Here "Locals" expanded by one level (short of knowing what to look for):

-   this0x19d9f9c4 {instance=0x  
externalTraceEnabled=false } SysInterpreterInstance *
+   instance0xInterpreterInstance *
externalTraceEnabledfalse   bool
h   Variable is optimized away and not available.   
-   i   0x19d9f9a8 
{context={instanceContext={functions=0x6354f544 {rexx.dll!RexxInstanceInterface 
InterpreterInstance::interfaceVector} {...} ...} ...} ...}   
InterpreterInstance *
+   RexxInternalObject  {header={objectSize=224 flags=2 
sizePadding=1666252802 } behaviour=rexx.dll!0x6355bf94 
{classType=T_InterpreterInstance (191) ...} }RexxInternalObject
+   context {instanceContext={functions=0x6354f544 
{rexx.dll!RexxInstanceInterface InterpreterInstance::interfaceVector} {...} 
...} ...}InstanceContext
+   sysInstance {instance=0x  
externalTraceEnabled=false }SysInterpreterInstance
+   rootActivity0x19d9f640 {instance=0x19d9f9a8 
{context={instanceContext={functions=0x6354f544 {rexx.dll!RexxInstanceInterface 
InterpreterInstance::interfaceVector} {...} ...} ...} ...} ...} Activity *
+   securityManager 0x19d9fd38 {manager=0x  } 
SecurityManager *
+   allActivities   0x19d9fa88 {...}QueueClass *
+   defaultEnvironment  0x19175b58 {hashValue=66842 length=3 
numberStringValue=0x  ...}   RexxString *
+   searchPath  0xRexxString *
+   searchExtensions0x19d9faf8 {IndexFlags=0 arraySize=4 
maximumSize=16 ...}ArrayClass *
applicationData 0x  void *
+   localEnvironment0x19d9ffa8 {methodTable=0x 
 unknownMethod=0x  } DirectoryClass *
+   commandHandlers 0x19d9fd50 {...}StringTable *
+   requiresFiles   0x19d9fb68 {...}StringTable *
terminating false   bool
terminated  false   bool
+   terminationSem  {sem=0x103c }   SysSemaphore
+   exits   0x19d9f9fc {{entryPoint=0x type=UNRESOLVED (0) 
}, {entryPoint=0x type=UNRESOLVED (0) }, ...}ExitHandler[17]
mode433717824   unsigned long
-   options 0x15e04558 {optionName=0x638b29a8 "RegisterLibrary" 
option={value={value_ARGLIST=0x1894ef24 {...} value_NAME=...} ...} }

[Oorexx-devel] Core Dumps on BSD

[P.O. Jonsson]

There is a lot of crashing running the testsuite on inter alia NetBSD and 
OpenBSD and I was astonished to see a test case failing that passed in the past:
[failure] 20211122 10:20:47.341167
  svn:r12118   Change date: 2020-10-31 16:59:59 +0100
  Test:   TEST_TREE_DIRECTORY
  Class:  SYSFILETREE.TESTGROUP
  File:   .../ooRexx/base/rexxutil/SysFileTree.testGroup
  Line:   431
  Failed: assertSame
Expected: 7
Actual:   8
Message:  SysFileTree(*, ) lines returned 
 11/21/21  12:00a   0  -rw-r--r--  
/home/osboxes/workspace/ooRexx-NetBSD-test/ooRexx/base/rexxutil/sysfiletree/f
11/21/21  12:00p   1  -rw-r--r--  
/home/osboxes/workspace/ooRexx-NetBSD-test/ooRexx/base/rexxutil/sysfiletree/.h
11/22/21  11:59p 999  -rw-r--r--  
/home/osboxes/workspace/ooRexx-NetBSD-test/ooRexx/base/rexxutil/sysfiletree/b b
 1/02/90   3:04a   2  -r--r--r--  
/home/osboxes/workspace/ooRexx-NetBSD-test/ooRexx/base/rexxutil/sysfiletree/UpperFile
11/22/21   5:20a 512  drwxr-xr-x  
/home/osboxes/workspace/ooRexx-NetBSD-test/ooRexx/base/rexxutil/sysfiletree/UpperDir
11/22/21   4:20a 512  drwxr-xr-x  
/home/osboxes/workspace/ooRexx-NetBSD-test/ooRexx/base/rexxutil/sysfiletree/d
11/22/21   1:20a 512  dr-xr-xr-x  
/home/osboxes/workspace/ooRexx-NetBSD-test/ooRexx/base/rexxutil/sysfiletree/.d
11/18/21  11:08p   590289288  -rw---  
/home/osboxes/workspace/ooRexx-NetBSD-test/ooRexx/base/rexxutil/sysfiletree/rexx.core
When I looked closer into rexx.core It had one page or so of (binary/hex) 
garbage and thereafter it looked as a copy of of worker.rex, the „engine“ of 
all the testing.

When is Rexx.core created and what is its purpose? I have noted that some of 
the test cases that core dump when run in a collection of tests pass without 
problem if I run the tests alone. Could it be that there is something in the 
test system that causes these crashes? How could it be debugged?

This is really annoying :-(

Hälsningar/Regards/Grüsse,
P.O. Jonsson
oor...@jonases.se



___
Oorexx-devel mailing list
Oorexx-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/oorexx-devel