FWD » Core Development » Base Language

When a class has a static method call with buffer parameter, into a method/constructor, on DELETE OBJECT, FWD throws an java.lang.IllegalStateException:

Failures (1):
  FWD Test:tests.TestClassLoadByReference:testClassLoad
    MethodSource [className = 'com.goldencode.testcases.tests.TestClassLoadByReference', methodName = 'testClassLoad', methodParameterTypes = '']
    => java.lang.RuntimeException: invoke() of program tests.TestClassLoadByReference failed
       com.goldencode.p2j.util.ControlFlowOps.invokeError(ControlFlowOps.java:8547)
       com.goldencode.p2j.util.ControlFlowOps.invokeLegacyMethod(ControlFlowOps.java:5270)
       com.goldencode.p2j.util.ControlFlowOps.invokeLegacyMethod(ControlFlowOps.java:5158)
       com.goldencode.p2j.util.ObjectOps.invoke(ObjectOps.java:4912)
       com.goldencode.p2j.util.ObjectOps.invokeStandalone(ObjectOps.java:2717)
       [...]
     Caused by: java.lang.reflect.InvocationTargetException
       java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
       java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:77)
       java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
       java.base/java.lang.reflect.Method.invoke(Method.java:569)
       com.goldencode.p2j.util.ControlFlowOps$InternalEntryCaller.invokeImpl(ControlFlowOps.java:9760)
       [...]
     Caused by: java.lang.IllegalStateException: Tracking for local/tstcasesdb/primary is unbalanced!
       com.goldencode.p2j.persist.TxWrapper$WorkArea.trackDatabase(TxWrapper.java:1158)
       com.goldencode.p2j.persist.TxWrapper$TxWrapperHelper.trackDatabase(TxWrapper.java:725)
       com.goldencode.p2j.persist.BufferManager.trackDatabase(BufferManager.java:3046)
       com.goldencode.p2j.persist.BufferManager.deregisterDynamicBuffer(BufferManager.java:1858)
       com.goldencode.p2j.persist.RecordBuffer.resourceDeleted(RecordBuffer.java:8046)
       [...]

Test case:

TestClassLoadByReference.clsTestClassLoadByReference.cls

BLOCK-LEVEL ON ERROR UNDO, THROW.

USING tests.ObjectTest FROM PROPATH.

CLASS tests.TestClassLoadByReference:
    @Test.
    METHOD PUBLIC VOID TestClassLoad():
        DEFINE VARIABLE obj AS tests.ObjectTest.
        obj = NEW tests.ObjectTest().
        DELETE OBJECT obj.
    END METHOD.
END CLASS.

ObjectTest.clsObjectTest.cls

USING tests.StaticClass FROM PROPATH.

CLASS tests.ObjectTest:
    CONSTRUCTOR PUBLIC ObjectTest ():
        Method1().
    END CONSTRUCTOR.

    METHOD PUBLIC VOID Method1():
        StaticClass:TestGetBuf(BUFFER adaptivept1).
    END METHOD.
END CLASS.

CLASS tests.StaticClass:
    METHOD STATIC PUBLIC VOID TestGetBuf(BUFFER bTest FOR adaptivept1):
    END METHOD.
END CLASS.

Complete FWD logs:Complete FWD logs:

╷
├─ JUnit Jupiter ✔
├─ JUnit Vintage ✔
├─ JUnit Platform Suite ✔
└─ FWD Test ✔
   └─ tests.TestClassLoadByReference ✔
      └─ testClassLoad ✘ invoke() of program tests.TestClassLoadByReference failed

Failures (1):
  FWD Test:tests.TestClassLoadByReference:testClassLoad
    MethodSource [className = 'com.goldencode.testcases.tests.TestClassLoadByReference', methodName = 'testClassLoad', methodParameterTypes = '']
    => java.lang.RuntimeException: invoke() of program tests.TestClassLoadByReference failed
       com.goldencode.p2j.util.ControlFlowOps.invokeError(ControlFlowOps.java:8547)
       com.goldencode.p2j.util.ControlFlowOps.invokeLegacyMethod(ControlFlowOps.java:5270)
       com.goldencode.p2j.util.ControlFlowOps.invokeLegacyMethod(ControlFlowOps.java:5158)
       com.goldencode.p2j.util.ObjectOps.invoke(ObjectOps.java:4912)
       com.goldencode.p2j.util.ObjectOps.invokeStandalone(ObjectOps.java:2717)
       [...]
     Caused by: java.lang.reflect.InvocationTargetException
       java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
       java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:77)
       java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
       java.base/java.lang.reflect.Method.invoke(Method.java:569)
       com.goldencode.p2j.util.ControlFlowOps$InternalEntryCaller.invokeImpl(ControlFlowOps.java:9760)
       [...]
     Caused by: java.lang.IllegalStateException: Tracking for local/tstcasesdb/primary is unbalanced!
       com.goldencode.p2j.persist.TxWrapper$WorkArea.trackDatabase(TxWrapper.java:1158)
       com.goldencode.p2j.persist.TxWrapper$TxWrapperHelper.trackDatabase(TxWrapper.java:725)
       com.goldencode.p2j.persist.BufferManager.trackDatabase(BufferManager.java:3046)
       com.goldencode.p2j.persist.BufferManager.deregisterDynamicBuffer(BufferManager.java:1858)
       com.goldencode.p2j.persist.RecordBuffer.resourceDeleted(RecordBuffer.java:8046)
       [...]

Teodor, please upload the test with the .p programs.

• p-buf-ref.pp-buf-ref.p

  USING tests.StaticClass FROM PROPATH.
  
  PROCEDURE p1:
      StaticClass:TestGetBuf(BUFFER adaptivept1).
  END PROCEDURE.
  

• Test classTest class

  BLOCK-LEVEL ON ERROR UNDO, THROW.
  
  USING tests.ObjectTest FROM PROPATH.
  
  CLASS tests.TestClassLoadByReference:
      @Test.
      METHOD PUBLIC VOID TestClassLoad():
          DEFINE VARIABLE hdl AS HANDLE NO-UNDO.
          RUN p-buf-ref.p PERSISTENT SET hdl.
          RUN p1 IN hdl.
          DELETE PROCEDURE hdl.
      END METHOD.
  END CLASS.
  

Teodor, please test this change with the unit-test in question. In RecordBuffer:

   protected Boolean delayed = null;

   public void finished()
   {
      // calculate the 'delayed' flag only once
      if (delayed == null)
      {
         // need to be sure delayed is not polluted by a previous call
         delayed = !isDynamic() && txHelper.isExternalBlock();
      }

The root cause I think it was because the delayed flag was calculated more than once - this needs to be done only when the defining external procedure exits (persistent or not).

The current changes in 10336a are not OK.

Committed revision 16068 on task branch 10336a:
- Reverted rev 16067. Modify delayed flag only once, according to #10336-8.

This solution is way better than what I have found.
I have tested this with the persistent procedure/class instance buffer and this fixed the issue.

I will test this change with some FWD converted applications to see if there are no other issues regarding this change.

Revision 16097 is causing a regression in a customer application. I will revert 10336a to unfreeze a trunk delivery and then I will later post a stack trace with the error.

Stack trace:

ErrorManager.displayError(String, boolean, String[], boolean, boolean) line: 3550    
ErrorManager.recordOrThrowError(int[], String[], boolean, boolean, boolean, boolean) line: 2037    
ErrorManager.recordOrThrowError(int[], String[], boolean, boolean, boolean) line: 1922    
ErrorManager.recordOrThrowError(int[], String[], boolean, boolean) line: 1891    
ErrorManager.recordOrThrowError(int, String, boolean) line: 1820    
ErrorManager.recordOrThrowError(int, String) line: 1799    
RecordBuffer.errorNotAvailable(String) line: 12656    
TemporaryBuffer(RecordBuffer).errorNotAvailable() line: 12679    
RecordBuffer$Handler.invoke(Object, Method, Object[]) line: 12992    
$__Proxy2017.get<redacted>(int) line: not available    
GeneratedMethodAccessor1198.invoke(Object, Object[]) line: not available    
DelegatingMethodAccessorImpl.invoke(Object, Object[]) line: 43    
Method.invoke(Object, Object...) line: 569    
Utils.invoke(Method, Object, Object...) line: 1787    
TemporaryBuffer$ReferenceProxy.invoke(Object, Method, Object[]) line: 9721    
$__Proxy2018.get<redacted>(int) line: not available    
$__Proxy2018.get<redacted>(NumberType) line: not available    

Doesn't look very verbose... will check the OE code for a testcase.

Testcase is a bit difficult but from what I see there is a temp-table buffer reference and when the procedure that declares the temp-table using an .i file execute's function ends the temp-table is dereferenced and the entire temp-table becomes empty leading to the error. Before doing target.deleted() in TransactionManager.processFinalizables delayed is false but if we re-compute it it's true. In rev. 16097 this re-computation is skipped so finishedImpl is called but in trunk where it works worldScope is set.

I will try to have 2 procedures use an include file where a temp-table is declared, have the scope of one procedure end and see if the other procedure's temp-table still has records. This is my lead so far.

Șerban Bursuc wrote:

Testcase is a bit difficult but from what I see there is a temp-table buffer reference and when the procedure that declares the temp-table using an .i file execute's function ends the temp-table is dereferenced and the entire temp-table becomes empty leading to the error. Before doing target.deleted() in TransactionManager.processFinalizables delayed is false but if we re-compute it it's true. In rev. 16097 this re-computation is skipped so finishedImpl is called but in trunk where it works worldScope is set.

I will try to have 2 procedures use an include file where a temp-table is declared, have the scope of one procedure end and see if the other procedure's temp-table still has records. This is my lead so far.

On preprocessing step, preprocessor include directives like .i what are you referring to, are replaced with actual .i preprocessor result. Please also look in .p.cache files. If the testcase is hard to reproduce, please tell me how to reproduce (in pm).

Testcase:

proc1.p:

{table.i}

create tt.
tt.f1 = "a".

define variable hProc2 as handle.

run proc2.p persistent set hProc2 (input this-procedure).
run display-recs in hProc2.

proc2.p:

{table.i}

define input parameter hParent as handle.

procedure init:
    define parameter buffer ttB for tt.
    ttB.f1 = "c".
end procedure.

create tt.
tt.f1 = "b".
run init (buffer tt).

procedure display-recs:
    define variable msg as character.
    for each tt:
        message tt.f1.
        msg = tt.f1.
    end.

    if msg = "" then do:
        message "no records found! gg.".
    end.
end.

table.i:

define temp-table tt no-undo
field f1 as character.

This doesn't have anything to do with include files. I think 10336a was fixing a valid bug, if we check in proc1 after running the persistent set what records are in tt it's a, I think this is what Teodor was fixing (?), but in this case it looks like the buffer isn't cleared after the initial scope of proc2 ends, OE knows that another potential call in the same procedure can occur and it's keeping the modified "stale" value of the procedure for future use, that's why it sees c.

Șerban Bursuc wrote:

Testcase:

proc1.p:
[...]

proc2.p:
[...]

table.i:
[...]

This doesn't have anything to do with include files. I think 10336a was fixing a valid bug, if we check in proc1 after running the persistent set what records are in tt it's a, I think this is what Teodor was fixing (?), but in this case it looks like the buffer isn't cleared after the initial scope of proc2 ends, OE knows that another potential call in the same procedure can occur and it's keeping the modified "stale" value of the procedure for future use, that's why it sees c.

Thanks!
I will tests this and I will rethink the solution, with this in mind.