Menu
▾
▴
[Oorexx-bugs] [ oorexx-Bugs-1919081 ] Crash in rexx dll when calling RexxStart
|
From: SourceForge.net <no...@so...> - 2008-05-30 13:15:09
|
Bugs item #1919081, was opened at 2008-03-18 21:58 Message generated for change (Comment added) made by bigrixx You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=684730&aid=1919081&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: None Status: Open Resolution: None Priority: 5 Private: No Submitted By: Jean-Noel Guillerme (guillerme) Assigned to: Nobody/Anonymous (nobody) Summary: Crash in rexx dll when calling RexxStart Initial Comment: Hi, Our software has been developed using half C++ and half object rexx. The C++ part uses the rexx API (rexxStar..) to communicate with the rexx scripts. It's a multithreaded application. It has up to 5 threads running the rexx code. The rexx interface has been running for almost 10 years, with no rexx problem. Our rexx scripts were written using classic rexx. Recently, we've developped new rexx modules using Object rexx. Since then, we have stability issues. Our application crashes in the rexx DLL. It seems to be a concurrency access problem as it would only crash if we have more than one thread running rexx. I did some testing using ooRexx runtime (tokenized rexx files) and ooRexx interpreter. I had crashes in both configurations, but at different location of the rexx dll. I managed to reproduce the problem in a small sample. I enclose it. To reproduce the issue, just run rexxstart. The binary expects a rexx file named crashtest.rex. I've enclosed both tokenisez and untokenized version. Just remove the _tok to test the tokenized script. Any feedback would be appreciated as this problem some huge impacts for some of our clients. Thanks you ! ---------------------------------------------------------------------- >Comment By: Rick McGuire (bigrixx) Date: 2008-05-30 09:15 Message: Logged In: YES user_id=1125291 Originator: NO This is looking like some sort of race condition during initialization when multiple threads are getting used. This code has already been significantly rewritten in the trunk version, and there's another large update under development in my sandbox. I'm not sure there's much point spending time debugging this in the 3.2.0 version. ---------------------------------------------------------------------- Comment By: dominic wise (domwise) Date: 2008-05-29 21:13 Message: Logged In: YES user_id=1382455 Originator: NO I don't know if this is relevant, but when I changed the earlier four line example so that B was simply a subclass of A, I could not get the crash to occur. ---------------------------------------------------------------------- Comment By: dominic wise (domwise) Date: 2008-05-29 20:54 Message: Logged In: YES user_id=1382455 Originator: NO Following is a stack trace for a crash using the simple example I gave, running the RexxStart sample over a freshly compiled debug build of OORexx 3.2.0. All threads active in the Rexx interepreter are shown. One thread (not shown) had just exited the interpreter when the crash occurred. Crashing thread - 'this' was NULL: --------------------------------------- RexxBehaviour::setTypenum() Line 109 RexxBehaviour::subclass() Line 326 RexxClass::subclass() Line 1245 RexxSource::processInstall() Line 1325 RexxSource::install() Line 189 RexxActivation::run() Line 253 RexxMethod::call() Line 318 RexxObject::shriekRun() Line 1637 SysRunProgram() Line 1689 ... Other Rexx threads ---------------------------------------- RexxActivity::releaseKernel() Line 1512 SysReadProgram() Line 365 RexxSource::initFile() Line 207 RexxSource::classNewFile() Line 4711 RexxMethodClass::newFile() Line 829 SysRunProgram() Line 1656 ... RexxActivityClass::addWaitingActivity() Line 2773 RexxActivity::requestKernel() Line 1535 SysRestoreTranslatedProgram() Line 521 SysRestoreProgram() Line 159 SysRunProgram() Line 1653 ... RexxActivity::waitKernel() Line 214 RexxActivityClass::addWaitingActivity() Line 2801 RexxActivity::yield() Line 1499 RexxMethod::run() Line 254 RexxObject::messageSend() Line 713 RexxObject::sendMessage() Line 248 RexxClass::subclass() Line 1286 RexxSource::processInstall() Line 1325 RexxSource::install() Line 189 RexxActivation::run() Line 253 RexxMethod::call() Line 318 RexxObject::shriekRun() Line 1637 SysRunProgram() Line 1689 ... RexxActivity::waitKernel() Line 214 RexxActivityClass::addWaitingActivity() Line 2801 RexxActivity::requestKernel() Line 1535 SysReadProgram() Line 360 RexxSource::initFile() Line 207 RexxSource::classNewFile() Line 4711 RexxMethodClass::newFile() Line 829 SysRunProgram() Line 1656 ... For all threads, ... is: RexxLocal::runProgram() Line 395 RexxMethod::run() Line 197 RexxObject::messageSend() Line 713 RexxActivity::messageSend() Line 3746 RexxStart() Line 671 CRexxThread::StartRexx() Line 71 Parameters have been removed as most were pointers and would have badly broken the above layout. I have the full stack trace if anyone wants to see it but I can't attach it to the bug of mail it through SourceForge. I'll need a "real" email address to send it to. ---------------------------------------------------------------------- Comment By: Moritz Hoffmann (antiguru) Date: 2008-05-29 04:41 Message: Logged In: YES user_id=1267170 Originator: NO Hi, I downloaded your code and had a look at it. First of all, I could not exactly reproduce your bug. Running ooRexx 3.2.0 on WinXP, your application got stuck in an endless loop. One explanation for this is that your main thread waits for all threads to end (isRunning == false) until the main thread and with it the process ends. One problem I see is that the main thread will not give the other threads a chance to run as the loop calling isOneThreadRunning() has no delay mechanism. Because of this the application doesn't crash on my machine, but still I think there may be a problem with ooRexx threading. It would be very helpful if you could add a stack trace of the failing applications. This gives us the chance to figure out where the problem might be. The stack trace can usually be generated running the application in a debugger or loading a core dump into a debugger. If you can reproduce the error with ~abs, and if it has a different reason, then open another bug report for it, including minimal sample application and stack trace. Regards, Moritz ---------------------------------------------------------------------- Comment By: Jean-Noel Guillerme (guillerme) Date: 2008-05-28 20:58 Message: Logged In: YES user_id=2040121 Originator: YES I've tried the rexx code you provided and I confirmed it crashed in my environment. FYI, I also crashed with the following command: say (-43.5009)~abs Cheers ---------------------------------------------------------------------- Comment By: dominic wise (domwise) Date: 2008-05-28 08:17 Message: Logged In: YES user_id=1382455 Originator: NO Thanks for providing the source. While there appear to be one or two possible errors concerning the C run-time in the program, I can reproduce the problem with the following minimal replacement for crashtest.rex return 0 ::class A subclass class public ::method init ::class B public metaclass A Please check if the above crashes in your environment. ---------------------------------------------------------------------- Comment By: Jean-Noel Guillerme (guillerme) Date: 2008-05-27 23:12 Message: Logged In: YES user_id=2040121 Originator: YES Thanks for the update. I've enclosed the source for my rexxstart program. File Added: rexxstart.zip ---------------------------------------------------------------------- Comment By: dominic wise (domwise) Date: 2008-05-27 22:19 Message: Logged In: YES user_id=1382455 Originator: NO Last comment from myself - did not realise that comments can be submitted when not logged in ---------------------------------------------------------------------- Comment By: Nobody/Anonymous (nobody) Date: 2008-05-27 22:17 Message: Logged In: NO I think you will need to provide the source for your rexxstart program in order that this can be properly investigated. Without this it will be impossible to tell whether or not the Rexx API is being used correctly ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=684730&aid=1919081&group_id=119701 |