#1761 oorexx on the BSD:s

[Niclas Rosenvik]

I have been trying to get oorexx to compile on Net, Free and OpenBSD .
A patch for this is attached.
Comments on the patch:
BSD don't have libdl, use CMAKE_DL_LIBS instead of hardcoding dl.
CMAKE_DL_LIBS is set to dl on systems that have it.
sys/stat.h is where S_IWUSR etc are defined according to posix.
It is needed to get these on NetBSD in
common/platform/unix/SysFile.hpp and sys/stat.h is assumed
to be always available in other parts of the code
(interpreter/platform/unix/SysFileSystem.hpp) so always include
it.
arpa/inet.h was needed to get htons etc on FreeBSD.
Instead of setting HOST_NAME_MAX to _POSIX_HOST_NAME_MAX for
certain OS:s set it if HOST_NAME_MAX is not defined and
_POSIX_HOST_NAME_MAX is available. This should work on all
platforms.

[Niclas Rosenvik]

Sorry I filed this in bugs it should have gone to patches

[Per Olov Jonsson]

I append this here, the provided patch made the build go through but the testing showed quite some problems. Even excluding the samples and the native APIs there are plenty of problems.

Please also note that freeBSD install to /usr/bin NOT to /usr/local/bin

[Per Olov Jonsson]

Correction: freeBSD install to /usr/local/bin. OpenIndiana on the other hand install to /usr/bin

[Niclas Rosenvik]

I have tried to run the tests on Net and OpenBSD and it segdumps. Running gdb backtrace shows on all crashes that Activity is NULL when it runs Activity::checkStackSpace, I have no clue why this happens.

[Per Olov Jonsson]

I do not have Net or OpenBSD and there is no official build for any of them yet. I have experienced the segdumps to happen only the first time I run a new setup but it normally dissapears, if you have a reproducible scenario with segdumps maybe you can upload the tracefile and indicate the place where it happends maybe one of the developers can get something out of it.

Maybe add some basic info on the build as well (where is it installing, bitness etc)

[Per Olov Jonsson]

We now have FreeBSD OpenBSD and OpenIndiana runnning on the Jenkins buildmachine.

Regarding the segfaults this is what I found out so far: OpenBSD is building just fine but testing is resulting in a segfault unless the "untick" option -U is used. By tracing I found out that the testing on OpenBSD can be made to run again with ticks disabled. I traced the culprit back to ooTest.frm. I think there is something wrong in in

::class 'PhaseReport'
somewhere around here, starting at line 2474
::method tickTock unguarded
The segfaults come back when the -U parameter is removed in the testing

The tickTock method claims to spawn a 2nd process, maybe this is critical on a multi-user multi-tasking (virtual) machine with only one core?

also Alarm.testGroup seems to provoke a segfault so I have excluded (-x) it for now.

[Niclas Rosenvik]

I have just tested to run the tes suite on NetBSD and it does not segfault if I use the -U option. it does not finish though. it seems to not get past TIME.testGroup.

[Rick McGuire]

There have been problems like this in the past where the cause was in how
the classes in SysSemaphore.cpp were getting built. This caused the mutexes
to not work at all, so anything that used multiple threads would just
crash. I was never involved in troubleshooting these issues, so I don't
recall the specifics of the solution.

Rick

On Thu, May 13, 2021 at 5:37 AM Niclas Rosenvik nros@users.sourceforge.net
wrote:

I have just tested to run the tes suite on NetBSD and it does not segfault
if I use the -U option. it does not finish though. it seems to not get past
TIME.testGroup.

---

** [bugs:#1761] oorexx on the BSD:s**

Status: open
Group: 5.0.0
Labels: BSD
Created: Tue May 04, 2021 12:22 PM UTC by Niclas Rosenvik
Last Updated: Thu May 13, 2021 08:32 AM UTC
Owner: nobody
Attachments:

• oorexx-bsd.patch (sourceforge.net)
  (5.2 kB; text/x-patch)

I have been trying to get oorexx to compile on Net, Free and OpenBSD .
A patch for this is attached.
Comments on the patch:
BSD don't have libdl, use CMAKE_DL_LIBS instead of hardcoding dl.
CMAKE_DL_LIBS is set to dl on systems that have it.
sys/stat.h is where S_IWUSR etc are defined according to posix.
It is needed to get these on NetBSD in
common/platform/unix/SysFile.hpp and sys/stat.h is assumed
to be always available in other parts of the code
(interpreter/platform/unix/SysFileSystem.hpp) so always include
it.
arpa/inet.h was needed to get htons etc on FreeBSD.
Instead of setting HOST_NAME_MAX to _POSIX_HOST_NAME_MAX for
certain OS:s set it if HOST_NAME_MAX is not defined and
_POSIX_HOST_NAME_MAX is available. This should work on all
platforms.

---

Sent from sourceforge.net because you indicated interest in <
https://sourceforge.net/p/oorexx/bugs/1761/>

To unsubscribe from further messages, please visit <
https://sourceforge.net/auth/subscriptions/>

[Erich]

There have been problems like this in the past where the cause was in how
the classes in SysSemaphore.cpp were getting built.
This caused the mutexes to not work at all, so anything that used multiple threads would just crash.

I checked the DEFINEs in SysSemaphore - all are found

-- Looking for pthread.h
-- Looking for pthread.h - found
-- Looking for pthread_mutexattr_settype
-- Looking for pthread_mutexattr_settype - found
-- Looking for pthread_mutex_timedlock
-- Looking for pthread_mutex_timedlock - found
-- Performing Test HAVE_PTHREAD_MUTEX_ERRORCHECK
-- Performing Test HAVE_PTHREAD_MUTEX_ERRORCHECK - Success
-- Performing Test HAVE_PTHREAD_MUTEX_RECURSIVE
-- Performing Test HAVE_PTHREAD_MUTEX_RECURSIVE - Success

Running this TstConcurrencyCooperate.rex test where two threads switch back and forth works when I run at most two switches back/forth (other platforms than OpenBSD work fine, of course, with any number of switches)

-- concurrent cooperating Rexx threads

use strict arg switches = 5000

t = .Cooperation~new(switches)
m1 = .Message~new(t, "first")
m1~start
m2 = .Message~new(t, "second")
m2~start
.StdOut~charOut(switches "back and forth task switches")

m1~wait
m2~wait
.StdOut~say(" in" t~timing~format(, 2) "seconds," (switches / t~timing)~format(, 0) "switches/sec")

::class Cooperation

::attribute timing

::method init
  expose switches turn
  use strict arg switches
  turn = 1 -- we start with method 'first'

::method first unguarded
  expose switches turn
  do switches
    guard on when turn = 1 -- wait until it's our turn
    turn = 2 -- signal our sibling
    guard off
  end

::method second unguarded
  expose switches turn timing
  call time("r")
  do switches
    guard on when turn = 2 -- wait until it's our turn
    turn = 1 -- signal our sibling
    guard off
  end
  timing = time("e")

When running three switches back/forth in the debugger, I get

$ PATH=/home/osboxes/oorexxbuild/bin:$PATH gdb ./rexx
GNU gdb 6.3

(gdb) run ~/TstConcurrencyCooperate.rex 3
Starting program: /home/osboxes/oorexxbuild/bin/rexx ~/TstConcurrencyCooperate.rex 3
Error while reading shared library symbols:
Dwarf Error: wrong version in compilation unit header (is 4, should be 2) [in module /usr/libexec/ld.so]
3 back and forth task switches
Program received signal SIGSEGV, Segmentation fault.
[Switching to thread 601624]
_ZN12HashContents9hashIndexEP18RexxInternalObject (this=0xf0617556d70, index=0x0)
    at oorexxsvn/main/trunk/interpreter/classes/support/HashContents.hpp:204
204             return (ItemLink)(index->getHashValue() % bucketSize);

(gdb) backtrace full
#0  _ZN12HashContents9hashIndexEP18RexxInternalObject (this=0xf0617556d70, index=0x0)
    at oorexxsvn/main/trunk/interpreter/classes/support/HashContents.hpp:204
#1  0x00000f06a44778df in _ZN12HashContents3putEP18RexxInternalObjectS1_ (this=0xf0617556d70, value=0xf0681935850, index=0x0)
    at /home/osboxes/oorexxsvn/main/trunk/interpreter/classes/support/HashContents.cpp:232
        position = 16521200356538
        previous = 16518929240160
#2  0x00000f06a44750c3 in _ZN14HashCollection3putEP18RexxInternalObjectS1_ (this=0xf0617556d40, value=0xf0681935850, index=0x0)
    at /home/osboxes/oorexxsvn/main/trunk/interpreter/classes/support/HashCollection.cpp:427
#3  0x00000f06a44c80c6 in _ZN12RexxVariable6informEP8Activity (this=0xf06175553a0, informee=0x0)
    at /home/osboxes/oorexxsvn/main/trunk/interpreter/execution/RexxVariable.cpp:130
#4  0x00000f06a45207f9 in _ZN18RexxSimpleVariable8setGuardEP14RexxActivation (this=0xf061754bdc0, context=0xf06175572e0)
    at /home/osboxes/oorexxsvn/main/trunk/interpreter/expression/ExpressionVariable.cpp:335
        variable = (class RexxVariable *) 0xf06175553a0
#5  0x00000f06a453a79e in _ZN20RexxInstructionGuard7executeEP14RexxActivationP15ExpressionStack (this=0xf061754c760, context=0xf06175572e0,
    stack=0xf0617557438) at /home/osboxes/oorexxsvn/main/trunk/interpreter/instructions/GuardInstruction.cpp:144
        i = 0
        result = (class RexxObject *) 0xf061754ca30
#6  0x00000f06a44ab2cb in _ZN14RexxActivation3runEP10RexxObjectP10RexxStringPS1_mP15RexxInstructionR15ProtectedObject (this=0xf06175572e0,
    _receiver=0xf0617554cc0, name=0xf0617555d20, _arglist=0xf0617555dd0, _argcount=0, start=0x0, resultObj=@0xf061ce8d498)
    at /home/osboxes/oorexxsvn/main/trunk/interpreter/execution/RexxActivation.cpp:592
        nextInst = (class RexxInstruction *) 0xf061754c760
        t = (class RexxActivation *) 0xb7
        frame = {<> = {_vptr$ActivationFrame = 0xf06a45d85e8, next = 0x0, activity = 0xf0617555f10}, activation = 0xf06175572e0}
#7  0x00000f06a44bc2eb in _ZN8RexxCode3runEP8ActivityP11MethodClassP10RexxObjectP10RexxStringPS5_mR15ProtectedObject (this=0xf061754cd20,
    activity=0xf0617555f10, method=0xf061754cd90, receiver=0xf0617554cc0, msgname=0xf0617555d20, argPtr=0xf0617555dd0, argcount=0,
    result=@0xf061ce8d498) at /home/osboxes/oorexxsvn/main/trunk/interpreter/execution/RexxCode.cpp:210
        newacta = (class RexxActivation *) 0xf06175572e0
#8  0x00000f06a4431d69 in _ZN11MethodClass3runEP8ActivityP10RexxObjectP10RexxStringPS3_mR15ProtectedObject (this=0xf061754cd90,
    activity=0xf0617555f10, receiver=0xf0617554cc0, msgname=0xf0617555d20, argPtr=0xf0617555dd0, count=0, result=@0xf061ce8d498)
    at /home/osboxes/oorexxsvn/main/trunk/interpreter/classes/MethodClass.cpp:171
#9  0x00000f06a4449f7a in _ZN10RexxObject11messageSendEP10RexxStringPPS_mR15ProtectedObject (this=0xf0617554cc0, msgname=0xf0617555d20,
    arguments=0xf0617555dd0, count=0, result=@0xf061ce8d498) at /home/osboxes/oorexxsvn/main/trunk/interpreter/classes/ObjectClass.cpp:900
        method_save = (class MethodClass *) 0xf061754cd90
        error = Error_No_method_name
#10 0x00000f06a442f8cc in _ZN12MessageClass8dispatchEv (this=0xf0617555e50)
    at /home/osboxes/oorexxsvn/main/trunk/interpreter/classes/MessageClass.cpp:444
        myActivity = (class Activity *) 0xf0617555f10
        result = {<> = {_vptr$ProtectedBase = 0xf06a45ceae8, next = 0x0, activity = 0xf0617555f10}, protectedObject = 0x0}
#11 0x00000f06a4504fe3 in _ZN17MessageDispatcher3runEv (this=0xf061ce8d5f0)
    at /home/osboxes/oorexxsvn/main/trunk/interpreter/concurrency/MessageDispatcher.cpp:54
#12 0x00000f06a44c2dc8 in _ZN16NativeActivation3runER18ActivityDispatcher (this=0xf06175571e0, dispatcher=@0xf061ce8d5f0)
    at /home/osboxes/oorexxsvn/main/trunk/interpreter/execution/NativeActivation.cpp:1631
        activityLevel = 1
#13 0x00000f06a4505abe in _ZN8Activity3runER18ActivityDispatcher (this=0xf0617555f10, target=@0xf061ce8d5f0)
    at /home/osboxes/oorexxsvn/main/trunk/interpreter/concurrency/Activity.cpp:3282
        startDepth = 1
        base = 3846
        activityLevel = 1
        newNActa = (class NativeActivation *) 0xf06175571e0
#14 0x00000f06a4505828 in _ZN8Activity9runThreadEv (this=0xf0617555f10)
    at /home/osboxes/oorexxsvn/main/trunk/interpreter/concurrency/Activity.cpp:216
        dispatcher = {<> = {_vptr$ActivityDispatcher = 0xf06a45d8988, rc = 0, conditionData = 0x0, activity = 0xf0617555f10,
    activation = 0xf06175571e0}, message = 0xf0617555e50}
        activityLevel = 1
        firstDispatch = false
        base = 0
#15 0x00000f06a456ec52 in _Z9threadFncPv (args=0xf0617555f10) at /home/osboxes/oorexxsvn/main/trunk/interpreter/platform/unix/SysActivity.cpp:61
#16 0x00000f0611151f51 in _rthread_start (v=Variable "v" is not available.
) at /usr/src/lib/librthread/rthread.c:96
        thread = Variable "thread" is not available.

So it seems that GUARD cannot find its WHEN variable any more.
Into what direction is this pointing?

(There are other issues I don't understand, but these may be just some side effects:

• What is the above "Dwarf Error" telling us? The error only shows when running rexx in the debugger
• What is happening at the bottom of the stack at #16 - it doesn't get down to main
  )

[Rick McGuire]

On Wed, May 26, 2021 at 12:05 PM Erich erich_st@users.sourceforge.net
wrote:

There have been problems like this in the past where the cause was in how
the classes in SysSemaphore.cpp were getting built.
This caused the mutexes to not work at all, so anything that used
multiple threads would just crash.

I checked the DEFINEs in SysSemaphore - all are found
~~~
-- Looking for pthread.h
-- Looking for pthread.h - found
-- Looking for pthread_mutexattr_settype
-- Looking for pthread_mutexattr_settype - found
-- Looking for pthread_mutex_timedlock
-- Looking for pthread_mutex_timedlock - found
-- Performing Test HAVE_PTHREAD_MUTEX_ERRORCHECK
-- Performing Test HAVE_PTHREAD_MUTEX_ERRORCHECK - Success
-- Performing Test HAVE_PTHREAD_MUTEX_RECURSIVE
-- Performing Test HAVE_PTHREAD_MUTEX_RECURSIVE - Success
~~~

Running this TstConcurrencyCooperate.rex test where two threads switch
back and forth works when I run at most two switches back/forth (other
platforms than OpenBSD work fine, of course, with any number of switches)

~~~
-- concurrent cooperating Rexx threads

use strict arg switches = 5000

t = .Cooperation~new(switches)
m1 = .Message~new(t, "first")
m1~start
m2 = .Message~new(t, "second")
m2~start
.StdOut~charOut(switches "back and forth task switches")

m1~wait
m2~wait
.StdOut~say(" in" t~timing~format(, 2) "seconds," (switches /
t~timing)~format(, 0) "switches/sec")

::class Cooperation

::attribute timing

::method init
expose switches turn
use strict arg switches
turn = 1 -- we start with method 'first'

::method first unguarded
expose switches turn
do switches
guard on when turn = 1 -- wait until it's our turn
turn = 2 -- signal our sibling
guard off
end

::method second unguarded
expose switches turn timing
call time("r")
do switches
guard on when turn = 2 -- wait until it's our turn
turn = 1 -- signal our sibling
guard off
end
timing = time("e")
~~~

When running three switches back/forth in the debugger, I get

~~~
$ PATH=/home/osboxes/oorexxbuild/bin:$PATH gdb ./rexx
GNU gdb 6.3

(gdb) run ~/TstConcurrencyCooperate.rex 3
Starting program: /home/osboxes/oorexxbuild/bin/rexx
~/TstConcurrencyCooperate.rex 3
Error while reading shared library symbols:
Dwarf Error: wrong version in compilation unit header (is 4, should be 2)
[in module /usr/libexec/ld.so]
3 back and forth task switches
Program received signal SIGSEGV, Segmentation fault.
[Switching to thread 601624]
_ZN12HashContents9hashIndexEP18RexxInternalObject (this=0xf0617556d70,
index=0x0)
at
oorexxsvn/main/trunk/interpreter/classes/support/HashContents.hpp:204
204 return (ItemLink)(index->getHashValue() % bucketSize);

(gdb) backtrace full

i've never seen anything like this before but the index value for used for
the variable name is NULL. I have no theories on how that might happen. I
still suspect a problem with the semaphores, but if GUARD instructions are
involved, it might be a problem with the event semaphores, not the mutexes.

0 _ZN12HashContents9hashIndexEP18RexxInternalObject (this=0xf0617556d70,

index=0x0)
at
oorexxsvn/main/trunk/interpreter/classes/support/HashContents.hpp:204

1 0x00000f06a44778df in ZN12HashContents3putEP18RexxInternalObjectS1

(this=0xf0617556d70, value=0xf0681935850, index=0x0)
at
/home/osboxes/oorexxsvn/main/trunk/interpreter/classes/support/HashContents.cpp:232
position = 16521200356538
previous = 16518929240160

2 0x00000f06a44750c3 in ZN14HashCollection3putEP18RexxInternalObjectS1

(this=0xf0617556d40, value=0xf0681935850, index=0x0)
at
/home/osboxes/oorexxsvn/main/trunk/interpreter/classes/support/HashCollection.cpp:427

3 0x00000f06a44c80c6 in _ZN12RexxVariable6informEP8Activity

(this=0xf06175553a0, informee=0x0)
at
/home/osboxes/oorexxsvn/main/trunk/interpreter/execution/RexxVariable.cpp:130

4 0x00000f06a45207f9 in

_ZN18RexxSimpleVariable8setGuardEP14RexxActivation (this=0xf061754bdc0,
context=0xf06175572e0)
at
/home/osboxes/oorexxsvn/main/trunk/interpreter/expression/ExpressionVariable.cpp:335
variable = (class RexxVariable *) 0xf06175553a0

5 0x00000f06a453a79e in

_ZN20RexxInstructionGuard7executeEP14RexxActivationP15ExpressionStack
(this=0xf061754c760, context=0xf06175572e0,
stack=0xf0617557438) at
/home/osboxes/oorexxsvn/main/trunk/interpreter/instructions/GuardInstruction.cpp:144
i = 0
result = (class RexxObject *) 0xf061754ca30

6 0x00000f06a44ab2cb in

_ZN14RexxActivation3runEP10RexxObjectP10RexxStringPS1_mP15RexxInstructionR15ProtectedObject
(this=0xf06175572e0,
_receiver=0xf0617554cc0, name=0xf0617555d20, _arglist=0xf0617555dd0,
_argcount=0, start=0x0, resultObj=@0xf061ce8d498)
at
/home/osboxes/oorexxsvn/main/trunk/interpreter/execution/RexxActivation.cpp:592
nextInst = (class RexxInstruction ) 0xf061754c760
t = (class RexxActivation ) 0xb7
frame = {<> = {_vptr$ActivationFrame = 0xf06a45d85e8, next = 0x0,
activity = 0xf0617555f10}, activation = 0xf06175572e0}

7 0x00000f06a44bc2eb in

_ZN8RexxCode3runEP8ActivityP11MethodClassP10RexxObjectP10RexxStringPS5_mR15ProtectedObject
(this=0xf061754cd20,
activity=0xf0617555f10, method=0xf061754cd90, receiver=0xf0617554cc0,
msgname=0xf0617555d20, argPtr=0xf0617555dd0, argcount=0,
result=@0xf061ce8d498) at
/home/osboxes/oorexxsvn/main/trunk/interpreter/execution/RexxCode.cpp:210
newacta = (class RexxActivation *) 0xf06175572e0

8 0x00000f06a4431d69 in

_ZN11MethodClass3runEP8ActivityP10RexxObjectP10RexxStringPS3_mR15ProtectedObject
(this=0xf061754cd90,
activity=0xf0617555f10, receiver=0xf0617554cc0, msgname=0xf0617555d20,
argPtr=0xf0617555dd0, count=0, result=@0xf061ce8d498)
at
/home/osboxes/oorexxsvn/main/trunk/interpreter/classes/MethodClass.cpp:171

9 0x00000f06a4449f7a in

_ZN10RexxObject11messageSendEP10RexxStringPPS_mR15ProtectedObject
(this=0xf0617554cc0, msgname=0xf0617555d20,
arguments=0xf0617555dd0, count=0, result=@0xf061ce8d498) at
/home/osboxes/oorexxsvn/main/trunk/interpreter/classes/ObjectClass.cpp:900
method_save = (class MethodClass *) 0xf061754cd90
error = Error_No_method_name

10 0x00000f06a442f8cc in _ZN12MessageClass8dispatchEv (this=0xf0617555e50)

at

/home/osboxes/oorexxsvn/main/trunk/interpreter/classes/MessageClass.cpp:444
myActivity = (class Activity *) 0xf0617555f10
result = {<> = {_vptr$ProtectedBase = 0xf06a45ceae8, next = 0x0,
activity = 0xf0617555f10}, protectedObject = 0x0}

11 0x00000f06a4504fe3 in _ZN17MessageDispatcher3runEv (this=0xf061ce8d5f0)

at

/home/osboxes/oorexxsvn/main/trunk/interpreter/concurrency/MessageDispatcher.cpp:54

12 0x00000f06a44c2dc8 in _ZN16NativeActivation3runER18ActivityDispatcher

(this=0xf06175571e0, dispatcher=@0xf061ce8d5f0)
at
/home/osboxes/oorexxsvn/main/trunk/interpreter/execution/NativeActivation.cpp:1631
activityLevel = 1

13 0x00000f06a4505abe in _ZN8Activity3runER18ActivityDispatcher

(this=0xf0617555f10, target=@0xf061ce8d5f0)
at
/home/osboxes/oorexxsvn/main/trunk/interpreter/concurrency/Activity.cpp:3282
startDepth = 1
base = 3846
activityLevel = 1
newNActa = (class NativeActivation *) 0xf06175571e0

14 0x00000f06a4505828 in _ZN8Activity9runThreadEv (this=0xf0617555f10)

at

/home/osboxes/oorexxsvn/main/trunk/interpreter/concurrency/Activity.cpp:216
dispatcher = {<> = {_vptr$ActivityDispatcher = 0xf06a45d8988, rc =
0, conditionData = 0x0, activity = 0xf0617555f10,
activation = 0xf06175571e0}, message = 0xf0617555e50}
activityLevel = 1
firstDispatch = false
base = 0

15 0x00000f06a456ec52 in _Z9threadFncPv (args=0xf0617555f10) at

/home/osboxes/oorexxsvn/main/trunk/interpreter/platform/unix/SysActivity.cpp:61

16 0x00000f0611151f51 in _rthread_start (v=Variable "v" is not available.

) at /usr/src/lib/librthread/rthread.c:96
thread = Variable "thread" is not available.
~~~

So it seems that GUARD cannot find its WHEN variable any more.
Into what direction is this pointing?

(There are other issues I don't understand, but these may be just some
side effects:
- What is the above "Dwarf Error" telling us? The error only shows when
running rexx in the debugger
- What is happening at the bottom of the stack at #16 - it doesn't get
down to main
)

---

** [bugs:#1761] oorexx on the BSD:s**

Status: open
Group: 5.0.0
Labels: BSD
Created: Tue May 04, 2021 12:22 PM UTC by Niclas Rosenvik
Last Updated: Thu May 13, 2021 10:17 AM UTC
Owner: nobody
Attachments:

• oorexx-bsd.patch (sourceforge.net)
  (5.2 kB; text/x-patch)

I have been trying to get oorexx to compile on Net, Free and OpenBSD .
A patch for this is attached.
Comments on the patch:
BSD don't have libdl, use CMAKE_DL_LIBS instead of hardcoding dl.
CMAKE_DL_LIBS is set to dl on systems that have it.
sys/stat.h is where S_IWUSR etc are defined according to posix.
It is needed to get these on NetBSD in
common/platform/unix/SysFile.hpp and sys/stat.h is assumed
to be always available in other parts of the code
(interpreter/platform/unix/SysFileSystem.hpp) so always include
it.
arpa/inet.h was needed to get htons etc on FreeBSD.
Instead of setting HOST_NAME_MAX to _POSIX_HOST_NAME_MAX for
certain OS:s set it if HOST_NAME_MAX is not defined and
_POSIX_HOST_NAME_MAX is available. This should work on all
platforms.

---

Sent from sourceforge.net because you indicated interest in <
https://sourceforge.net/p/oorexx/bugs/1761/>

To unsubscribe from further messages, please visit <
https://sourceforge.net/auth/subscriptions/>

[Rick McGuire]

I've taken a closer look at the stack trace and can see what is going on. The exception is caused by a null pointer used to add an object to an IdentityTable. The object in question should be the pointer to the current activity, from a call at line 130 in RexxVariable.cpp. This means that the field ActivityManager::currentActivity is NULL while there is active running Rexx code, something that should never happen.

The only way this could happen like this is for the semaphores that are used for thread dispatch to not be working correctly. Again, this points to the issue being a problem with how the semaphores are getting built for this platform.

[Per Olov Jonsson]

Ok, I am having the same on OpenBSD. Add -x TIME.testGroup to the command line and run until it balks again and then add the testGroup it balks on that time after TIME.testGroup. I am installing NetBSD on a virtual machine right now but since I am a newbie on NetBSD and all the *nixes use different package handlers it will take some time. The normal install did not eve add a user so I am starting really from scratch here. Also have a look at #213 , I added some remarks there since this is most likely a bug on BSD that we cannot capture just yet.

[Per Olov Jonsson]

@Nicklas: maybe we can take this off the list to save some bandwith? I have a dozen of questions on how to get NetBSD set up correctly. You can contact me on oorexx@jonases.se

[Erich]

Revision [r12269] adds an alternate code path using sysctl CTL_KERN, KERN_PROC, KERN_PROC_PATHNAME to identify the currently running executable on BSDs without installed /proc/..

Though on the OpenBSD 6.9 on which we currently build, KERN_PROC_PATHNAME is undefined and thus also this alternative fails.

[Per Olov Jonsson]

We now have ooRexx building stably on FreeBSD OpenBSD and NetBSD, can we close this ticket?
There are still problems in the testing on the BSDs (segmentation faults), I would like to open a ticket for that, I think it is related to the way the threads (in the testing framework) are dispatched as Rick explains above.

[Niclas Rosenvik]

From my perspective, yes.

[Niclas Rosenvik]

The bugs concerning threads etc can also be in the respective OS it does not have to be oorexx fault.

[Erich]

Did the TstConcurrencyCooperate.rex issue mentioned above go away with a new OpenBSD installation?
I could run it successfully on all of our three BSDs

[Per Olov Jonsson]

I will have a look 👀 next year

Von meinem iPhone gesendet

Am 31.12.2021 um 18:57 schrieb Erich erich_st@users.sourceforge.net:

Did the TstConcurrencyCooperate.rex issue mentioned above go away with a new OpenBSD installation?
I could run it successfully on all of our three BSDs

---

** [bugs:#1761] oorexx on the BSD:s**

Status: open
Group: 5.0.0
Labels: BSD
Created: Tue May 04, 2021 12:22 PM UTC by Niclas Rosenvik
Last Updated: Fri Dec 31, 2021 02:59 PM UTC
Owner: nobody
Attachments:

• oorexx-bsd.patch (sourceforge.net) (5.2 kB; text/x-patch)

I have been trying to get oorexx to compile on Net, Free and OpenBSD .
A patch for this is attached.
Comments on the patch:
BSD don't have libdl, use CMAKE_DL_LIBS instead of hardcoding dl.
CMAKE_DL_LIBS is set to dl on systems that have it.
sys/stat.h is where S_IWUSR etc are defined according to posix.
It is needed to get these on NetBSD in
common/platform/unix/SysFile.hpp and sys/stat.h is assumed
to be always available in other parts of the code
(interpreter/platform/unix/SysFileSystem.hpp) so always include
it.
arpa/inet.h was needed to get htons etc on FreeBSD.
Instead of setting HOST_NAME_MAX to _POSIX_HOST_NAME_MAX for
certain OS:s set it if HOST_NAME_MAX is not defined and
_POSIX_HOST_NAME_MAX is available. This should work on all
platforms.

---

Sent from sourceforge.net because you indicated interest in https://sourceforge.net/p/oorexx/bugs/1761/

To unsubscribe from further messages, please visit https://sourceforge.net/auth/subscriptions/

[Anonymous]

I have repeatedly tested on FreeBSD OpenBSD and NetBSD and the test passed everytime. Also from my point of view you can close this ticket.

FreeBSD

osboxes@osboxes:~ $ which rexx
/home/osboxes/workspace/ooRexx-FreeBSD-build/oorexxBuild/bin/rexx

osboxes@osboxes:~ $ rexx TstConcurrencyCooperate.rex
5000 back and forth task switches in 0.07 seconds, 67666 switches/sec
osboxes@osboxes:~ $ rexx TstConcurrencyCooperate.rex
5000 back and forth task switches in 0.13 seconds, 38030 switches/sec
osboxes@osboxes:~ $ rexx TstConcurrencyCooperate.rex
5000 back and forth task switches in 0.12 seconds, 41801 switches/sec
osboxes@osboxes:~ $ rexx TstConcurrencyCooperate.rex
5000 back and forth task switches in 0.08 seconds, 62723 switches/sec
osboxes@osboxes:~ $ rexx TstConcurrencyCooperate.rex
5000 back and forth task switches in 0.10 seconds, 50136 switches/sec

OpenBSD

OpenBSD7$ which rexx
/home/osboxes/workspace/ooRexx-OpenBSD-build/oorexxBuild/bin/rexx

OpenBSD7$ rexx TstConcurrencyCooperate.rex
5000 back and forth task switches in 0.36 seconds, 13879 switches/sec
OpenBSD7$ rexx TstConcurrencyCooperate.rex
5000 back and forth task switches in 0.41 seconds, 12119 switches/sec
OpenBSD7$ rexx TstConcurrencyCooperate.rex
5000 back and forth task switches in 0.39 seconds, 12949 switches/sec
OpenBSD7$ rexx TstConcurrencyCooperate.rex
5000 back and forth task switches in 0.41 seconds, 12100 switches/sec
OpenBSD7$ rexx TstConcurrencyCooperate.rex
5000 back and forth task switches in 0.37 seconds, 13573 switches/sec
OpenBSD7$ rexx TstConcurrencyCooperate.rex
5000 back and forth task switches in 0.41 seconds, 12074 switches/sec
OpenBSD7$

NetBSD

localhost$ which rexx
/home/osboxes/workspace/ooRexx-NetBSD-build/oorexxBuild/bin/rexx

localhost$ rexx TstConcurrencyCooperate.rex
5000 back and forth task switches in 0.06 seconds, 87679 switches/sec
localhost$ rexx TstConcurrencyCooperate.rex
5000 back and forth task switches in 0.05 seconds, 107416 switches/sec
localhost$ rexx TstConcurrencyCooperate.rex
5000 back and forth task switches in 0.05 seconds, 106803 switches/sec
localhost$ rexx TstConcurrencyCooperate.rex
5000 back and forth task switches in 0.05 seconds, 103016 switches/sec
localhost$ rexx TstConcurrencyCooperate.rex
5000 back and forth task switches in 0.05 seconds, 110495 switches/sec