Mark Miesfeld wrote:
> Pull in my last commit and see if it works.
>   
Thanks, that solved the problem, could compile a new version.

Running it will exhibit the same behaviour (while cleaning up the Rexx
proxy cache within BSF4Rexx; Rexx program output from ooRexxUnit in bold):

    ... cut ...
    *** <-- returning from: .._jniRexxUnregisterRexxObject(...), thisTid=[4776]
    *** --> arrived: .._jniRexxUnregisterRexxObject(...), thisTid=[4776]
    ---> RgfRemoveProxyObject(), begin: c_obj_id=[263139679] (identityHash)
    --------------> ooRexx->AttachThread() - RgfRemoveProxyObject... done. 
rc=[1]-------------->
         ---> RgfRemoveProxyObject2, begin: rtc=[7DD0BF3C], obj_id=[7D788028]
    *File search:        00:00:00.390000*
              RgfRemoveProxyObject2, acquired REGISTRY_lock, before 
rtc->SendMessage1(...) ...
              RgfRemoveProxyObject2, before getting count: 
OREXX_REGISTRY_REFCOUNTER=[7F244DE0], rtc->SendMessage1(OREXX_REGISTRY
    _REFCOUNTER, "AT", obj_id)=[7D77E428]
              RgfRemoveProxyObject2, retrieved 'refs'=[0]
              RgfRemoveProxyObject2, before removing from 
OREXX_REGISTRY=[7F244B60]...
    *Suite construction: 00:00:00.093000*          RgfRemoveProxyObject2, 
before removing from OREXX_REGISTRY_REFCOUNTER=[7F244DE0]
    ...

         <--- RgfRemoveProxyObject2, end: refs=[0]
    <-------------- ooRexx->DetachThread() - RgfRemoveProxyObject... done. 
<--------------
    <--- RgfRemoveProxyObject(), end:   c_obj_id=[263139679], remaining 
references=[0]
    *** <-- returning from: .._jniRexxUnregisterRexxObject(...), thisTid=[4776]
    *Test execution:     00:00:08.000000*
    *** --> arrived: .._jniRexxUnregisterRexxObject(...), thisTid=[4776]
    ---> RgfRemoveProxyObject(), begin: c_obj_id=[263139979] (identityHash)
    --------------> ooRexx->AttachThread() - RgfRemoveProxyObject... done. 
rc=[1]-------------->
         ---> RgfRemoveProxyObject2, begin: rtc=[7DD0BF3C], obj_id=[7D78D1A0]
    *Total time:         00:00:08.593000*
              RgfRemoveProxyObject2, acquired REGISTRY_lock, before 
rtc->SendMessage1(...) ...
              RgfRemoveProxyObject2, before getting count: 
OREXX_REGISTRY_REFCOUNTER=[7F244DE0]
    , rtc->SendMessage1(OREXX_REGISTRY_REFCOUNTER, "AT", obj_id)=[7D78B790]
              RgfRemoveProxyObject2, retrieved 'refs'=[0]
              RgfRemoveProxyObject2, before removing from 
OREXX_REGISTRY=[7F244B60]...
    #
    # An unexpected error has been detected by Java Runtime Environment:
    #
    #  EXCEPTION_ACCESS_VIOLATION (0xc0000005) at pc=0x004489ee, pid=1728, 
tid=4776
    #
    # Java VM: Java HotSpot(TM) Client VM (11.0-b16 mixed mode, sharing 
windows-x86)
    # Problematic frame:
    # C  [rexx.dll+0x189ee]
    #
    # An error report file with more information is saved as:
    # F:\work\svn\oorexx\test\releases\4.0.0\hs_err_pid1728.log
    #
    # If you would like to submit a bug report, please visit:
    #   http://java.sun.com/webapps/bugreport/crash.jsp
    # The crash happened outside the Java Virtual Machine in native code.
    # See problematic frame for where to report the bug.
    #
      


:-((

Notabene: the error is intermittent, though if it occurs it occurs right
in the above sequence (after the Rexx code has finished, while still
Java objects get finalized, causing a callback to Rexx via BSF4Rexx).

---rony


------------------------------------------------------------------------------
Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day 
trial. Simplify your report design, integration and deployment - and focus on 
what you do best, core application coding. Discover what's new with 
Crystal Reports now.  http://p.sf.net/sfu/bobj-july
_______________________________________________
Oorexx-devel mailing list
Oorexx-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/oorexx-devel

Reply via email to