#11 BSF4ooRexx returns wrong values

closed-fixed
Java (1)
5
2013-06-10
2012-10-30
Erik Duijs
No

There is a problem in BSF4ooRexx where it can return references to wrong (older) instances of java objects.
When this happens, this will gradually happen increasingly more frequently. It seems to be a problem in the registry of java objects.

I have attached a small self-contained example that demonstrates the issue.
In the example, we read values from java objects and report it when the value is not what we expect.

I've encountered this in version 410.20120618, which is the current release at this time.
I'm not aware of a real solution, although it is possible to minimize the chances of this happening in most cases by a significant amount (as commented in the example).

Discussion

  • Erik Duijs

    Erik Duijs - 2012-10-30

    program that demonstrates the reported problem

     
  • Rony G. Flatscher

    Erik, thank you very much for this report, especially the test program which is just great!

    Will take a while as my preliminary analysis and preliminiary experiments have not changed the behaviour, such that I will have to return to this problem, when I have more time in one piece on my hands!

     
  • Rony G. Flatscher

    Just an update: it turns out that the cause of this problem goes back to getting duplicate System.identityHashCode() for different Java instances! Therefore, if a Java object existed in the BSF registry with the same identityHashCode as a new Java object, then the Java object in the registry would not get replaced, rather a reference counter will get increased. Fetching that Java object from the BSF registry later will return the original Java object and in your test case its value gets returned which does not match the expected one. The longer the program runs, the more Java objects gets created the more likely identityHashCode collisions occur.

    OTOH, if the Java objects get removed from the BSF registry (manually or automagically via the ooRexx garbage collector), then these clashes are either not possible (in the manual case) or very unlikely, but still possible (in the ooRexx garbage collector triggered scenario).

     
  • Rony G. Flatscher

    Fixed with commit revision 115.

     
  • Rony G. Flatscher

    Will be reflected in next release.

     
  • Rony G. Flatscher

    • labels: --> Java
    • status: open --> pending-fixed
     
  • Rony G. Flatscher

    • assigned_to: nobody --> orexx
     
  • Rony G. Flatscher

    • status: pending-fixed --> closed-fixed
     

Log in to post a comment.

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

Sign up for the SourceForge newsletter:





No, thanks