#550 ooRexx 4.0.0 SVN 3619 greply.rex / AIX

v4.0
closed
None
5
2014-08-18
2008-10-27
No

Hello,
I still have a problem with greply.rex

./greply.rex

Using GUARDED method to wait until sum is complete:
Inside method sum_up: loop iteration 1000
Inside method sum_up: loop iteration 2000
Inside method sum_up: loop iteration 3000
Inside method sum_up: loop iteration 4000
Inside method sum_up: loop iteration 5000
Result should be 12502500: 12502500

Using UNGUARDED method to obtain an intermediate result:
Result should be less than 12502500: 11935
*** ERROR: At RexxMutex(), pthread_mutex_unlock - RC = 1 ! -> EPERM

No core dump.

The error message is from SysSemaphore.hpp

 /* added iRC here to catch hidden problems in the lock/unlock code */
 inline void request()
 {
   int iRC = 0;
   iRC = pthread_mutex_lock(&mutexMutex);
   if ( iRC )
   {
     fprintf(stderr," *** ERROR: At RexxMutex(), pthread_mutex_lock - RC = %d !\n", iRC);
   }
 }

 inline void release()
 {
   int iRC = 0;
   iRC = pthread_mutex_unlock(&mutexMutex);
   if ( iRC )
   {
     fprintf(stderr," *** ERROR: At RexxMutex(), pthread_mutex_unlock - RC = %d !\n", iRC);
   }
 }

Sorry, no solution to this problem yet.
No trace back avail. Maybe I can try to force a core dump in teh unlock code...

Bye
Rainer

Discussion

  • Rainer Tammer

    Rainer Tammer - 2008-10-27

    Hello,
    here the started rxapi do not help. I still get the unlock() error.

    Bye
    Rainer

     
  • Rick McGuire

    Rick McGuire - 2008-10-27

    Try setting a breakpoint at the place where the unlock error message is issued and get a stack traceback.

     
  • Rainer Tammer

    Rainer Tammer - 2008-10-27

    Hello,
    I can try this tomorrow (I have only a slow speed line to my build machine... debugging is not fun with it). This is the trace back. I added a assert(0) in the unlcok().

    dbx rexx

    Type 'help' for help.
    [using memory image in core]
    reading symbolic information ...

    IOT/Abort trap in pthread_kill at 0xd01247f4 ($t1)
    0xd01247f4 (pthread_kill+0x88) 80410014 lwz r2,0x14(r1)
    (dbx) where
    pthread_kill(??, ??) at 0xd01247f4
    _p_raise(??) at 0xd0124264
    raise.raise(??) at 0xd0377bd8
    abort.abort() at 0xd03d5ef8
    assert.assert_c99(??, ??, ??, ??) at 0xd03e0e4c
    RexxMemory.release()(0x2020e9d0), line 100 in "SysSemaphore.hpp"
    unlockKernel()(), line 762 in "ActivityManager.cpp"
    RexxActivity::releaseAccess()(this = 0x20340c10), line 1829 in "RexxActivity.cpp"
    returnActivity(RexxActivity*)(activityObject = 0x20340c10), line 836 in "ActivityManager.cpp"
    unnamed block in removeInactiveActivities()(this = 0x203381e8), line 430 in "InterpreterInstance.cpp"
    removeInactiveActivities()(this = 0x203381e8), line 430 in "InterpreterInstance.cpp"
    unnamed block in InterpreterInstance::terminate()(this = 0x203381e8), line 463 in "InterpreterInstance.cpp"
    InterpreterInstance::terminate()(this = 0x203381e8), line 463 in "InterpreterInstance.cpp"
    InstanceBlock::~InstanceBlock()(this = 0x2ff20880,
    dtorFlags = 2), line 405 in "Interpreter.cpp"
    ActivityDispatcher.invoke(_RXSYSEXIT,const char)(this = 0x2ff208e0, exits = (nil), env = "ksh"), line 122 in "ActivityDispatcher.cpp"
    RexxStart(argcount = 0, arglist = 0x2ff229b0, programname = "./greply.rex", instore = (nil), envname = "ksh", calltype = 0, exits = (nil), retcode = 0x2ff229c0, result = (nil)), line 172 in "InterpreterAPI.cpp"
    main(argc = 2, argv = 0x2ff22a70), line 161 in "rexx.cpp"

    Maybe this helps a bit...

    Bye
    Rainer

     
  • Rainer Tammer

    Rainer Tammer - 2008-10-27

    Hello,
    its better with 3621 but the error still shows up sometimes (5 of 20 times).

    One thing I do not understand is when does rxapi gets started automatically ??

    ktguard.rex - auto start rxapi
    usepipe.rex - auto start rxapi
    usecomp.rex - auto start rxapi
    stack.rex - no autostart og rxapi
    qtime.rex - no autostart og rxapi
    ...

    What is the difference ??

    bye
    Rainer

     
  • Rainer Tammer

    Rainer Tammer - 2008-10-27

    Hello,
    this is very strange... with 3622 the error seems gone...
    I will try to do a stress test tomorrow... If I get an error (+ trace back) I will post it here.

    Bye
    Rainer

     
  • Rick McGuire

    Rick McGuire - 2008-10-27

    In normal operation, rxapi will be started during system startup. However, if the daemon is not running when the interpreter is launched, it will attempt to start it so that it's available. If this is not on the path, this autostart will likely fail and operations that require rxapi might fail or hang. The attempt to start this will generally occur on the first operation that requires information from the rxapi process, such as an external function call or a queue operation.

     
  • Rainer Tammer

    Rainer Tammer - 2008-10-28

    Hello,
    good, so I will assure that the rxapi can be started (if neede).
    I will check all samples again. So we can ignore all failures related to a non started rxapi daemon.
    Should we print an error if the daemon is missing ???
    Bye
    Rainer

     
  • Rainer Tammer

    Rainer Tammer - 2008-10-29

    Hello,
    as all samples work if the rxapi daemon is started a call close would be appropriate.
    Bye
    Rainer

     


Anonymous

Cancel  Add attachments





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

Sign up for the SourceForge newsletter:





No, thanks