#160 Rexx hangs in semctl() on FreeBSD


I'm using version 3.0 from the FreeBSD ports package on
FreeBSD 6.1.

The traceback is below.

The workings is that vmpipe installs a bunch of
external functions, runs pwb.cmd, which in turn calls
back through the various external functions.

This was sitting in a select to wait for input on a
socket. When I hit ctl-c, the C program reports

PWB0070E: ERRNO on select: Interrupted system call

as it should. Then an error is returned to the REXX
program, but it does not seem to get there.

PWBWAIT() is the function that does the select() to
wait on the socket. At that point, ctl-c does not bite.

This worked on OS/2 in 1995. And on Linux last I
tried. Any insight?

(gdb) where

0 0x281f36cb in sys_semctl () from /lib/libc.so.6

1 0x281e9121 in semctl () from /lib/libc.so.6

2 0x28187576 in get_member_count (sid=65536) at


3 0x281875b8 in locksem (sid=65536, member=0) at


4 0x28184f8d in RxAPIStartUp (chain=0) at


5 0x28183c61 in RegQuery (name=0x811ca68 "PWBWAIT",

dll=0x0, exist=0xbfbfd2a6, usrwrd=0x0, type=2) at

6 0x28183d20 in RexxQueryFunction (name=0x811ca68

"PWBWAIT") at ./../rexxapi/SubcommandAPI.cpp:816

7 0x2812c811 in RegExternalFunction

(activation=0x8111340, activity=0x8113bf8,
target=0x811ca48, arguments=0x8435344, argcount=0,
calltype=0x80ff908, result=0xbfbfd41c)
at ./../kernel/bsd/ExternalFunctions.cpp:561

8 0x2812cac1 in SysExternalFunction

(activation=0x8111340, activity=0x8113bf8,
target=0x811ca48, parent=0x8114318,
arguments=0x8435344, argcount=0, calltype=0x80ff908,
foundFnc=0xbfbfd474) at

9 0x28139669 in RexxActivation::externalCall

(this=0x8111340, target=0x811ca48, argcount=0,
stack=0xbfbfd100, calltype=0x80ff908)
at ./../kernel/runtime/RexxActivation.cpp:1830

10 0x28115ced in RexxInstructionCall::execute

(this=0x814ef08, context=0x8111340, stack=0x811140c) at

11 0x2813a681 in RexxActivation::run (this=0x8111340,

arglist=0x8435304, argcount=0, start=0x2) at

12 0x2813b9bf in RexxActivation::internalCall

(this=0x8111158, target=0x814edb0, argcount=0,
stack=0xbfbfd100) at

13 0x2811256c in RexxExpressionFunction::evaluate

(this=0x81205f8, context=0x8111158, stack=0x8111224) at

14 0x281130ae in RexxUnaryOperator::evaluate

(this=0x8120610, context=0x8111158, stack=0x8111224) at

15 0x2811970e in RexxInstructionIf::execute

(this=0x8120630, context=0x8111158, stack=0x8111224) at

16 0x2813a681 in RexxActivation::run (this=0x8111158,

arglist=0x8435030, argcount=0, start=0x2) at

17 0x2813b9bf in RexxActivation::internalCall

(this=0x8110828, target=0x811f860, argcount=0,
stack=0xbfbfd100) at

18 0x2811256c in RexxExpressionFunction::evaluate

(this=0x811cf58, context=0x8110828, stack=0x81108f4) at

19 0x281169e1 in RexxInstructionDo::whileCondition

(this=0xbfbfd100, context=0x8110828, stack=0x81108f4)
at ./../kernel/instructions/DoInstruction.cpp:655

20 0x28117536 in RexxInstructionDo::reExecute

(this=0x811cf10, context=0x8110828, stack=0x81108f4,
doblock=0x8157d20) at

21 0x2811826b in RexxInstructionEnd::execute

(this=0x811f6a0, context=0x8110828, stack=0x81108f4) at

22 0x2813a681 in RexxActivation::run (this=0x8110828,

arglist=0x811419c, argcount=1, start=0x2) at

23 0x280f8b7f in RexxMethod::call (this=0x80af388,

activity=0x8113bf8, receiver=0x8113bf8,
msgname=0x80ff788, arguments=0x811419c, argcount=1,
environment=0x8154e78, context=135333928) at

24 0x281008d8 in RexxObject::shriekRun

(this=0x8113bf8, method=0x8154ea0, calltype=0x80ff908,
environment=0x8154e78, arguments=0x811419c, argCount=1)
at ./../kernel/classes/ObjectClass.cpp:1386

25 0x2812ea54 in SysRunProgram

(ControlInfo=0xbfbfd9f0) at ArrayClass.hpp:136

26 0x2814a359 in RexxLocal::runProgram

(this=0x8110810, arguments=0xbfbfd100) at

27 0x280f881c in RexxMethod::run (this=0x80c86a0,

activity=0x2814a348, receiver=0x8110810,
msgname=0x811407c, count=1, arguments=0x811407c)
at ./../kernel/classes/MethodClass.cpp:197

28 0x280ff979 in RexxObject::messageSend

(this=0x8110810, msgname=0x8114090, count=1,
arguments=0x811407c) at

29 0x281410f4 in RexxSendMessage (receiver=0x8110810,

msgname=0x28165f05 "RUN_PROGRAM", start_class=0x0,
interfacedefn=0x2815e195 "p", result_pointer=0x0)
at ArrayClass.hpp:134

30 0x2812e381 in RexxStart (argcount=-1077948160,

arglist=0xbfbfd100, programname=0xbfbfd100 "é\003\024",
instore=0xbfbfd100, envname=0xbfbfd100 "é\003\024",
calltype=-1077948160, exits=0xbfbfd100,
retcode=0xbfbfd100, result=0xbfbfd100) at

31 0x08049d6e in PwbRexxRun (base=0xbfbfebd0,

program=0x804fbf3 "pwbctl.cmd", argstr=0xbfbfdbc0 "cmd
cp q t") at ../pwbrexx.c:157

32 0x08049b48 in main (argc=1, argv=0xbfbfec44) at



  • John P. Hartmann

    Logged In: YES

    Should have mentioned that the process is consuming lots of
    CPU, so it is likely in a loop. And I use -lpthread.

    (gdb) step
    Single stepping until exit from function sys_semctl,
    which has no line number information.
    0x281e9121 in semctl () from /lib/libc.so.6
    Single stepping until exit from function semctl,
    which has no line number information.
    get_member_count (sid=65536) at
    230 return(semopts.buf->sem_nsems);
    Current language: auto; currently c++
    231 }
    locksem (sid=65536, member=0) at
    150 sem_lock.sem_num = member;
    169 }
    RxAPIStartUp (chain=0) at ./../rexxapi/RexxAPIManager.cpp:299
    299 if (!apidata){ / if memory
    anchor not attached
    321 apidata->rexxapisemaphore = SemId;
    323 attachall(chain); /get all
    shared memory blocks
    attachall (chain=0) at ./../rexxapi/RexxAPIManager.cpp:1730
    1730 switch (chain) {
    1760 if((apidata->baseblock[REGSUBCOMM] != 0)
    1763 apidata->sebase =
    attachshmem (shmid=196610) at
    111 return ((char)shmat(shmid, 0, 0)); / explicit
    conversion /
    113 }
    attachall (chain=674701312) at
    1769 apidata->macrobase =
    1763 apidata->sebase =
    1776 }
    RxAPIStartUp (chain=0) at ./../rexxapi/RexxAPIManager.cpp:325
    325 apidata->ThreadId=(pthread
    SysQueryThreadID () at ./../kernel/bsd/ThreadSupport.cpp:254
    254 }
    SysQueryThreadID () at ./../kernel/bsd/ThreadSupport.cpp:252
    252 return (int)pthread_self(); / just call
    the correct function

  • Rick McGuire

    Rick McGuire - 2007-04-16

    Logged In: YES
    Originator: NO

    Is this still a problem? We don't have a supported FreeBSD deliverable at the moment, so I think I'd like to close this.



Cancel  Add attachments

Get latest updates about Open Source Projects, Conferences and News.

Sign up for the SourceForge newsletter:

No, thanks