Ok, I see the problem. Please only report one problem per bug report. I'm
able to reproduce the problem by running run_90_testgroup.cmd, but the
requirement to run that program got lost in the bulk of this large bug
report. These are distinctly separate problems and should be opened and
tracked as separate bug reports.
Rick
On Fri, Sep 25, 2009 at 8:21 AM, Rony G. Flatscher <
rony.flatsc...@wu-wien.ac.at> wrote:
> Hi there,
>
> enclosed you'll find a bug report I filed regarding multithreading
> problems. The original message is at the top, the intermediate messages are
> given from the very bottom to the top.
>
> My problem currently: I get a crash each time I run the test, Rick doesn't.
>
>
> ---
>
> Debuging multithreading problems is sometimes complicated, and if the
> environment has complexity as well, it easily may turn into a nightmare. [As
> I have written in another report about a multithreading problem with ooRexx,
> I spent all of August and most of September in tracing down these problems
> (which may show up intermittently only, sometimes they are not repeatable),
> literally!}
>
> However, a total showstopper for me to proceed in my quest to get these
> multithreading problems sorted out, is a state where I get exceptions from
> my ooRexx builds and Rick doesn't.
>
> ---
>
> So in order to be sure that my builds are always picking up all changes I
> do a "svn update", and then run the following build script, which deletes
> the intermediate directories "Win32Rel" and "Win32Dbg" before creating the
> new interpreter:
>
> F:\work\svn\oorexx\main\trunk>type rgf_build_info.cmd
>
> rem assuming already path to ms-cpp (cl) set up, else:
> if not "%VCINSTALLDIR%" == "" goto sdk
> @echo Setting path to MSVCPP ...
> call E:\rony\dev\bsf\src\source_cc\env4_b22_xp.cmd
> @echo ---
>
> :sdk
> if not "%MSSdk%" == "" goto touchheaders
> @echo Setting up SDK for Windows Server 2003...
> rem path to SDK
> call "E:\Programme\Microsoft Platform SDK for Windows Server 2003
> R2\SetEnv.Cmd" /XP32 /RETAIL
> @echo ---
>
> :touchheaders
> rem touchheaders: this way no Xalan/Xerces needed
> @echo 'call touchheaders'
> call touchheaders
> @echo ---
>
> rem add NSIS path
> set PATH=%PATH%;D:\Programme\NSIS
>
> rem add path to Xalan and Xerces
> set PATH=%PATH%;F:\download\java\XalanXerces-C\bin
>
> rem pointers to source
> set SRC_DIR=\work\svn\oorexx\main\trunk
> set SRC_DRV=F:
>
> rem make sure entire interpreter gets built:
> @echo 'rm -rf Win32Rel'
> rm -rf Win32Rel
> @echo ---
> @echo 'rm -rf Win32Dbg'
> rm -rf Win32Dbg
> @echo ---
>
> makeorx BOTH PACKAGE
>
>
> Does anyone see a reason that I would pick up previously built files
> judging from this build script?
>
> If not, what can I do to make sure that my build is matching the checked
> out sources, other than deleting the build directories?
>
> Is it possible, that after uninstalling an ooRexx version and replacing it
> with a newly built-one that some left-overs of a previous installation may
> influence the behaviour of a newly built and installed version of ooRexx?
>
> Are there other reasons you can think of why the behaviour could be so
> different on two different machines building ooRexx from the same sources (I
> am working currently on a XP SP3)?
>
> How can we make sure to create ooRexx builds from trunk that match the
> sources and if using them are acceptable for bug reporting?
>
> Short of that, could someone please try to create a new build of ooRexx
> from trunk, follow the short instruction (at the top) of my bug report
> below, and run both scripts "run_80_testgroup.cmd" and
> "run_90_testgroup.cmd" and tell me whether you got an exception running
> "run_90_testgroup.cmd"? And if there is no crash of ooRexx running
> "run_90_testgroup.cmd" then make your build available to me (both, the
> release and the debug version)?
>
> TIA,
>
> ---rony
>
>
>
>
> -------- Original Message -------- Subject: [ oorexx-Bugs-2865707 ]
> Multithreading problems, 2 Date: Fri, 25 Sep 2009 11:51:18 +0000 From:
> SourceForge.net
> <nore...@sourceforge.net> <nore...@sourceforge.net> To:
> nore...@sourceforge.net
>
> Bugs item #2865707, was opened at 2009-09-24 09:14
> Message generated for change (Settings changed) made by bigrixx
> You can respond by visiting:
> https://sourceforge.net/tracker/?func=detail&atid=684730&aid=2865707&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: Interpreter
> Group: Next Release
> >Status: Pending
> Resolution: Fixed
> Priority: 5
> Private: No
> Submitted By: Rony G. Flatscher (orexx)
> Assigned to: Rick McGuire (bigrixx)
> Summary: Multithreading problems, 2
>
> Initial Comment:
> File is too large to upload with this report, it is available as "MT_bug.zip"
> at <http://wi.wu.ac.at/rgf/tmp/ooRexx/de_bug/>
> <http://wi.wu.ac.at/rgf/tmp/ooRexx/de_bug/>. This archive is created for the
> 32-bit ooRexx interpreter. [Please note, that accompanying files for
> debugging may be named "BSF4Rexx-32.*", whereas the dll in use is named
> "BSF4Rexx.dll", i.e. without the bitness information.]
>
> After download, unzip it, change into the directory "MT_bug" and run
> "setEnvironment.cmd", which will set up the PATH and CLASSPATH environment
> variables.
>
> Then run the batch files:
>
> run_80_testgroup.cmd
>
> ... this one will start a testgroup in which Rexx creates a Java object that
> will create Java threads that each create an own Rexx interpreter instance
> and run a Rexx script off it which itself will create Rexx threads to execute
> and interact with BSF4Rexx.
>
> Running these tests will cause an exception while Java is under control,
> yielding a hs*.log file that contains additional information including the
> call stack.
>
> This testgroup will bomb each time it gets run.
>
>
>
> ---
>
> run_90_testgroup.cmd
>
> ... this one will start a testgroup in which Rexx creates a Java object that
> will create Java threads that each reuse the same Rexx interpreter instance
> and run a Rexx script off it which itself will create Rexx threads to execute
> and interact with BSF4Rexx.
>
> This testgroup may execute without errors, but upon repetitions an exception
> occurs that one may use to get into the MS debugger.
>
>
> ----------------------------------------------------------------------
>
> >Comment By: Rick McGuire (bigrixx)
> Date: 2009-09-25 07:51
>
> Message:
> I have run this hundreds of times without a crash, only the error message
> you cited from the unit tests. Since I cannot confirm that you have
> correctly rebuilt the interpreter with this fix and can only go on what I'm
> able to reproduce, this problem is declared fixed. I repeat, to NOT reopen
> this again.
>
> ----------------------------------------------------------------------
>
> Comment By: Rony G. Flatscher (orexx)
> Date: 2009-09-25 07:44
>
> Message:
> The crash still occurs with my build of ooRexx (rev. 5208 from trunk),
> running "run_90_testgroup.cmd". An example of a call stack was supplied in
> this artefact a little bit earlier.
>
>
> ----------------------------------------------------------------------
>
> Comment By: Rick McGuire (bigrixx)
> Date: 2009-09-25 06:56
>
> Message:
> Just a quick look at this error shows that the bad object is a string with
> the value:
>
> "<O>org.rexxla.bsf.engines.rexx.rexxpr...@141d683"
>
> This definitely looks like something that was generated by your code.
> Tracking back through the stack, this object was the one passed in via a
> CallRoutine() API code, so this definitely looks like a problem in the
> BSFRexx code.
>
>
> ----------------------------------------------------------------------
>
> Comment By: Rick McGuire (bigrixx)
> Date: 2009-09-25 06:24
>
> Message:
> The bug you opened was for a crash, the crash has been fixed. If there are
> other issues, that is another problem that needs tracking on its own. Open
> a new problem report, do NOT reopen problems and dump them under a single
> problem.
>
> ----------------------------------------------------------------------
>
> Comment By: Rony G. Flatscher (orexx)
> Date: 2009-09-25 06:04
>
> Message:
> Just realized that for the call stack output I had used the non-debug
> version of 5208 trunk, so here is the call stack from the debug version,
> which therefore may be more helpful:
>
> > rexx.dll!SourceLocation::getLineNumber() Line 51 + 0xa bytes C++
> rexx.dll!RexxInstruction::getLineNumber() Line 79 + 0x12 bytes C++
> rexx.dll!RexxActivation::getContextLineNumber() Line 2511 C++
> rexx.dll!RexxActivation::createStackFrame() Line 4272 + 0x22 bytes
> C++
> rexx.dll!RexxActivationFrame::createStackFrame() Line 58 C++
> rexx.dll!RexxActivity::createExceptionObject(long errcode=40900,
> RexxString * description=0x00000000, RexxArray * additional=0x7f132818,
> RexxObject * result=0x00000000) Line 912 + 0xd bytes C++
> rexx.dll!RexxActivity::raiseException(long errcode=40900, RexxString *
> description=0x00000000, RexxArray * additional=0x7f132818, RexxObject *
> result=0x00000000) Line 759 + 0x18 bytes C++
> rexx.dll!RexxActivity::reportAnException(long errcode=40900, RexxObject
> * substitution1=0x7f575000) Line 511 C++
> rexx.dll!reportException(long error=40900, RexxObject * a1=0x7f575000)
> Line 159 C++
> rexx.dll!RaiseException1(RexxThreadContext_ * c=0x7f4e62a4, unsigned int
> n=40900, _RexxObjectPtr * o1=0x7f575000) Line 1715 C++
> BSF4Rexx.dll!RexxThreadContext_::RaiseException1(unsigned int n=40900,
> _RexxObjectPtr * o=0x7f575000) Line 1293 C++
> BSF4Rexx.dll!RexxCallContext_::RaiseException1(unsigned int n=40900,
> _RexxObjectPtr * o=0x7f575000) Line 2652 C++
> BSF4Rexx.dll!BSF_impl(RexxCallContext_ * context=0x0ac6f870,
> _RexxArrayObject * argArray=0x7f608998) Line 5200 C++
> BSF4Rexx.dll!BSF(RexxCallContext_ * context=0x0ac6f870, ValueDescriptor
> * arguments=0x0ac6f88c) Line 5146 + 0x17 bytes C++
> rexx.dll!RexxNativeActivation::callNativeRoutine(RoutineClass *
> _routine=0x7f12e8f0, RexxNativeRoutine * _code=0x7f12e8d0, RexxString *
> functionName=0x7f0a10b0, RexxObject * * list=0x7e1b7ccc, unsigned int
> count=2, ProtectedObject & resultObj={...}) Line 1319 C++
> rexx.dll!RexxNativeRoutine::call(RexxActivity * activity=0x7f4e6290,
> RoutineClass * routine=0x7f12e8f0, RexxString * functionName=0x7f0a10b0,
> RexxObject * * argPtr=0x7e1b7ccc, unsigned int count=2, ProtectedObject &
> result={...}) Line 316 C++
> rexx.dll!RoutineClass::call(RexxActivity * activity=0x7f4e6290,
> RexxString * msgname=0x7f0a10b0, RexxObject * * argPtr=0x7e1b7ccc, unsigned
> int argcount=2, ProtectedObject & result={...}) Line 234 C++
> rexx.dll!PackageManager::callNativeRoutine(RexxActivity *
> activity=0x7f4e6290, RexxString * name=0x7f0a10b0, RexxObject * *
> arguments=0x7e1b7ccc, unsigned int argcount=2, ProtectedObject &
> result={...}) Line 658 C++
> rexx.dll!SystemInterpreter::invokeExternalFunction(RexxActivation *
> activation=0x7f4a7818, RexxActivity * activity=0x7f4e6290, RexxString *
> target=0x7f0a10b0, RexxObject * * arguments=0x7e1b7ccc, unsigned int
> argcount=2, RexxString * calltype=0x7fd5cb00, ProtectedObject &
> result={...}) Line 272 + 0x17 bytes C++
> rexx.dll!RexxActivation::externalCall(RexxString * target=0x7f0a10b0,
> unsigned int _argcount=2, RexxExpressionStack * _stack=0x7f4a78d8,
> RexxString * calltype=0x7fd5cb00, ProtectedObject & resultObj={...}) Line
> 2626 + 0x25 bytes C++
> rexx.dll!RexxExpressionFunction::evaluate(RexxActivation *
> context=0x7f4a7818, RexxExpressionStack * stack=0x7f4a78d8) Line 225 C++
> rexx.dll!RexxExpressionMessage::evaluate(RexxActivation *
> context=0x7f4a7818, RexxExpressionStack * stack=0x7f4a78d8) Line 97 + 0x1b
> bytes C++
> rexx.dll!RexxInstructionReturn::execute(RexxActivation *
> context=0x7f4a7818, RexxExpressionStack * stack=0x7f4a78d8) Line 70 + 0x1b
> bytes C++
> rexx.dll!RexxActivation::run(RexxObject * _receiver=0x7f59a398,
> RexxString * msgname=0x7fcc4c20, RexxObject * * _arglist=0x00000000,
> unsigned int _argcount=0, RexxInstruction * start=0x00000000,
> ProtectedObject & resultObj={...}) Line 521 C++
> rexx.dll!RexxCode::run(RexxActivity * activity=0x7f4e6290, RexxMethod *
> method=0x7f0ca910, RexxObject * receiver=0x7f59a398, RexxString *
> msgname=0x7fcc4c20, RexxObject * * argPtr=0x00000000, unsigned int
> argcount=0, ProtectedObject & result={...}) Line 136 C++
> rexx.dll!RexxMethod::run(RexxActivity * activity=0x7f4e6290, RexxObject
> * receiver=0x7f59a398, RexxString * msgname=0x7fcc4c20, RexxObject * *
> argPtr=0x00000000, unsigned int count=0, ProtectedObject & result={...})
> Line 325 C++
> rexx.dll!RexxObject::messageSend(RexxString * msgname=0x7fcc4c20,
> RexxObject * * arguments=0x00000000, unsigned int count=0, ProtectedObject
> & result={...}) Line 793 C++
> rexx.dll!RexxObject::sendMessage(RexxString * message=0x7fcc4c20,
> ProtectedObject & result={...}) Line 439 + 0x1b bytes C++
> rexx.dll!RexxObject::sendMessage(RexxString * message=0x7fcc4c20) Line
> 618 C++
> rexx.dll!RexxObject::uninit() Line 2238 C++
> rexx.dll!UninitDispatcher::run() Line 55 C++
> rexx.dll!RexxNativeActivation::run(TrappingDispatcher &
> dispatcher={...}) Line 1642 C++
> rexx.dll!RexxActivity::run(TrappingDispatcher & target={...}) Line
> 3067 C++
> rexx.dll!RexxMemory::runUninits() Line 554 C++
> rexx.dll!RexxMemory::checkUninitQueue() Line 199 + 0x18 bytes C++
> rexx.dll!RexxActivation::run(RexxObject * _receiver=0x7ef4ef78,
> RexxString * msgname=0x7f2b4e90, RexxObject * * _arglist=0x7e1b7c34,
> unsigned int _argcount=0, RexxInstruction * start=0x00000000,
> ProtectedObject & resultObj={...}) Line 558 C++
> rexx.dll!RexxCode::run(RexxActivity * activity=0x7f4e6290, RexxMethod *
> method=0x7f2b5628, RexxObject * receiver=0x7ef4ef78, RexxString *
> msgname=0x7f2b4e90, RexxObject * * argPtr=0x7e1b7c34, unsigned int
> argcount=0, ProtectedObject & result={...}) Line 136 C++
> rexx.dll!RexxMethod::run(RexxActivity * activity=0x7f4e6290, RexxObject
> * receiver=0x7ef4ef78, RexxString * msgname=0x7f2b4e90, RexxObject * *
> argPtr=0x7e1b7c34, unsigned int count=0, ProtectedObject & result={...})
> Line 325 C++
> rexx.dll!RexxObject::messageSend(RexxString * msgname=0x7f2b4e90,
> RexxObject * * arguments=0x7e1b7c34, unsigned int count=0, ProtectedObject
> & result={...}) Line 793 C++
> rexx.dll!RexxExpressionStack::send(RexxString * message=0x7f2b4e90,
> unsigned int count=0, ProtectedObject & result={...}) Line 74 + 0x33
> bytes C++
> rexx.dll!RexxInstructionMessage::execute(RexxActivation *
> context=0x7f4e6048, RexxExpressionStack * stack=0x7f4e6108) Line 229 C++
> rexx.dll!RexxActivation::run(RexxObject * _receiver=0x7f4e6030,
> RexxString * msgname=0x7f2b2100, RexxObject * * _arglist=0x7e1b7cac,
> unsigned int _argcount=7, RexxInstruction * start=0x00000000,
> ProtectedObject & resultObj={...}) Line 521 C++
> rexx.dll!RexxActivation::dispatch() Line 377 + 0x33 bytes C++
> rexx.dll!RexxActivity::runThread() Line 126 C++
> rexx.dll!call_thread_function(void * arguments=0x7f4e6290) Line 63
> C++
> kernel32.dll!7c80b729()
> [Frames below may be incorrect and/or missing, no symbols loaded for
> kernel32.dll]
> rexx.dll!RexxStack::push(RexxObject * obj=0x00000002) Line 65 C++
> 00000118()
>
>
>
> ----------------------------------------------------------------------
>
> Comment By: Rony G. Flatscher (orexx)
> Date: 2009-09-25 05:56
>
> Message:
> Did build rev. 5208 from trunk and re-ran the tests from the very same
> package. Unfortunately, both tests still behave as before, the problem is
> NOT fixed yet.
>
> "run_80_testgroup.cmd"
>
> There should be no errors from running the Rexx scripts. The error shown:
>
> ... [begin] cut from the list of shown errors: ....
> TestNestedEngines: threadName=[null],
> Throwable=[org.rexxla.bsf.engines.rexx.RexxException:
> BSF4Rexx/routine/jniRexxRunProgra
> m(), error 8:
> 13 *-* testUnit=BsfRexxProxy(rpTestUnit, "ooRexxObject") -- get ooRexx
> object that gets proxied
> Error 40 running rexx line 13: Incorrect call to routine
> Error 40.900: BSF4Rexx/routine/BsfRexxProxy(), error 1: argument 1 must
> be RexxProxy object, received '<O>org.rexxla.bsf.eng
> ines.rexx.rexxpr...@141d683' of type 'The String class'.]
> ... [end] cut from the list of shown errors: ....
>
> >From the flow of control it is impossible that the string
> '<O>org.rexxla.bsf.eng
> ines.rexx.rexxpr...@141d683' is passed to the external Rexx routine
> BsfRexxProxy(). That string will be supplied to the public routine
> "bsf.wrap()" which is located in the Rexx package "BSF.CLS".
>
> BSF.WRAP() in this case (because of the leading '<O>') will return a
> BSF_Reference or a BSF_Array_Reference object (both classes defined in
> BSF.CLS as subclasses of BSF) instead, which then is used as an argument
> for BsfRexxProxy(). A BSF reference object allows one to interact with Java
> transparently.
>
> It seems therefore that BsfRexxProxy() gets the wrong argument supplied to
> (or for that matter BSF.WRAP() seems to return its received argument
> instead of the created BSF reference object).
>
> Maybe the following context information is helpful: all of this
> infrastructure is defined in the package BSF.CLS, so it would be possible
> to place debug statements there, if that would be needed. Please note, in
> case it matters, the class BSF is stored explicitly in .local, allowing for
> each Rexx interpreter instance an own copy to run. Via BSF's class methods
> one can excercise the public routines like bsf.wrap from native code as
> well, cf. RgfProcessJArgs() or BsfCreateRexxProxy() or
> ...jniSendRexxMessageToRexxObject(...) in BSF4Rexx.cc.
>
>
> ---------------
>
> "run_90_testgroup.cmd"
>
> Here e.g. the call stack from (there should not be an exception to be
> raised)
>
> > rexx.dll!002fb72e()
> [Frames below may be incorrect and/or missing, no symbols loaded for
> rexx.dll]
> rexx.dll!002fe8e0()
> rexx.dll!0030145e()
> rexx.dll!003024fe()
> rexx.dll!00300b8c()
> rexx.dll!0031aa6d()
> BSF4Rexx.dll!RexxThreadContext_::RaiseException1(unsigned int n=40900,
> _RexxObjectPtr * o=0x7f34ec68) Line 1293 C++
> BSF4Rexx.dll!RexxCallContext_::RaiseException1(unsigned int n=40900,
> _RexxObjectPtr * o=0x7f34ec68) Line 2652 C++
> BSF4Rexx.dll!BSF_impl(RexxCallContext_ * context=0x060ffbb4,
> _RexxArrayObject * argArray=0x7ef2bdb0) Line 5200 C++
> BSF4Rexx.dll!BSF(RexxCallContext_ * context=0x060ffbb4, ValueDescriptor
> * arguments=0x060ffab4) Line 5146 + 0x17 bytes C++
> rexx.dll!0030f441()
> kernel32.dll!7c80262a()
> kernel32.dll!7c802542()
> kernel32.dll!7c802600()
> kernel32.dll!7c802542()
> kernel32.dll!7c802600()
> kernel32.dll!7c802542()
>
>
>
> ----------------------------------------------------------------------
>
> Comment By: Rick McGuire (bigrixx)
> Date: 2009-09-24 16:01
>
> Message:
> Committed revision 5207
>
> ----------------------------------------------------------------------
>
> You can respond by visiting:
> https://sourceforge.net/tracker/?func=detail&atid=684730&aid=2865707&group_id=119701
>
>
> --
> --
> __________________________________________________________________________________
>
> Prof. Dr. Rony G. Flatscher
> Department Informationsverarbeitung und Prozessmanagement
> Institut für Betriebswirtschaftslehre und Wirtschaftsinformatik
> WU Wien
> Augasse 2-6
> A-1090 Wien/Vienna, Austria/Europe
> http://www.wu.ac.at (English: http://www.wu.ac.at/start/en)
> __________________________________________________________________________________
>
>
>
>
>
>
>
>
> ------------------------------------------------------------------------------
> Come build with us! The BlackBerry® Developer Conference in SF, CA
> is the only developer event you need to attend this year. Jumpstart your
> developing skills, take BlackBerry mobile applications to market and stay
> ahead of the curve. Join us from November 9-12, 2009. Register now!
> http://p.sf.net/sfu/devconf
> _______________________________________________
> Oorexx-devel mailing list
> Oorexx-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/oorexx-devel
>
>
------------------------------------------------------------------------------
Come build with us! The BlackBerry® Developer Conference in SF, CA
is the only developer event you need to attend this year. Jumpstart your
developing skills, take BlackBerry mobile applications to market and stay
ahead of the curve. Join us from November 9-12, 2009. Register now!
http://p.sf.net/sfu/devconf
_______________________________________________
Oorexx-devel mailing list
Oorexx-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/oorexx-devel
