Menu
▾
▴
[Oorexx-bugs] [ oorexx-Bugs-2201774 ] ooRexx 4.0.0 SVN 3619 greply.rex / AIX
|
From: SourceForge.net <no...@so...> - 2008-10-29 16:07:38
|
Bugs item #2201774, was opened at 2008-10-27 21:02 Message generated for change (Settings changed) made by tammer You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=684730&aid=2201774&group_id=119701 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: None Group: v4.0 Status: Closed >Resolution: None Priority: 5 Private: No Submitted By: Rainer Tammer (tammer) >Assigned to: Nobody/Anonymous (nobody) Summary: ooRexx 4.0.0 SVN 3619 greply.rex / AIX Initial Comment: 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 ---------------------------------------------------------------------- Comment By: Rainer Tammer (tammer) Date: 2008-10-29 17:04 Message: Hello, as all samples work if the rxapi daemon is started a call close would be appropriate. Bye Rainer ---------------------------------------------------------------------- Comment By: Rainer Tammer (tammer) Date: 2008-10-28 06:16 Message: 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 ---------------------------------------------------------------------- Comment By: Rick McGuire (bigrixx) Date: 2008-10-27 23:44 Message: 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. ---------------------------------------------------------------------- Comment By: Rainer Tammer (tammer) Date: 2008-10-27 23:27 Message: 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 ---------------------------------------------------------------------- Comment By: Rainer Tammer (tammer) Date: 2008-10-27 23:08 Message: 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 ---------------------------------------------------------------------- Comment By: Rainer Tammer (tammer) Date: 2008-10-27 21:58 Message: 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 ---------------------------------------------------------------------- Comment By: Rick McGuire (bigrixx) Date: 2008-10-27 21:52 Message: Try setting a breakpoint at the place where the unlock error message is issued and get a stack traceback. ---------------------------------------------------------------------- Comment By: Rainer Tammer (tammer) Date: 2008-10-27 21:18 Message: Hello, here the started rxapi do not help. I still get the unlock() error. Bye Rainer ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=684730&aid=2201774&group_id=119701 |