Derby
  1. Derby
  2. DERBY-4142

java.lang.VerifyError causing java.sql.SQLException: Cannot create an instance of generated class ... in lang.GeneratedColumnsTest and GeneratedColumnsPermsTest on IBM iseries

    Details

    • Type: Bug Bug
    • Status: Closed
    • Priority: Major Major
    • Resolution: Fixed
    • Affects Version/s: 10.5.1.1
    • Fix Version/s: 10.5.2.0, 10.6.1.0
    • Component/s: SQL
    • Labels:
      None
    • Environment:
      IBM iseries (AS 400) with ibm 1.5 (build 1.5.0_13-b05)
    • Issue & fix info:
      Patch Available
    • Bug behavior facts:
      Regression Test Failure

      Description

      This results in 22 errors.

      Here's the stack trace with an insane build:

      1) test_005_basicInsert(org.apache.derbyTesting.functionTests.tests.lang.GeneratedColumnsTest)java.sql.SQLException: Cannot create an instance of generated class org.apache.derby.exe.acd83d18d1x0120x62bdx2dffxffffb19003081.
      at java.lang.Throwable.<init>(Throwable.java:196)
      at java.lang.Exception.<init>(Exception.java:41)
      at java.sql.SQLException.<init>(SQLException.java:40)
      at org.apache.derby.impl.jdbc.EmbedSQLException.<init>(Unknown Source)
      at org.apache.derby.impl.jdbc.SQLExceptionFactory.getSQLException(Unknown Source)
      at org.apache.derby.impl.jdbc.Util.newEmbedSQLException(Unknown Source)
      at org.apache.derby.impl.jdbc.Util.seeNextException(Unknown Source)
      at org.apache.derby.impl.jdbc.TransactionResourceImpl.wrapInSQLException(Unknown Source)
      at org.apache.derby.impl.jdbc.TransactionResourceImpl.handleException(Unknown Source)
      at org.apache.derby.impl.jdbc.EmbedConnection.handleException(Unknown Source)
      at org.apache.derby.impl.jdbc.ConnectionChild.handleException(Unknown Source)
      at org.apache.derby.impl.jdbc.EmbedPreparedStatement.<init>(Unknown Source)
      at org.apache.derby.impl.jdbc.EmbedPreparedStatement20.<init>(Unknown Source)
      at org.apache.derby.impl.jdbc.EmbedPreparedStatement30.<init>(Unknown Source)
      at org.apache.derby.jdbc.Driver30.newEmbedPreparedStatement(Unknown Source)
      at org.apache.derby.impl.jdbc.EmbedConnection.prepareStatement(Unknown Source)
      at org.apache.derby.impl.jdbc.EmbedConnection.prepareStatement(Unknown Source)
      at org.apache.derbyTesting.functionTests.tests.lang.GeneratedColumnsHelper.chattyPrepare(GeneratedColumnsHelper.java:147)
      at org.apache.derbyTesting.functionTests.tests.lang.GeneratedColumnsHelper.goodStatement(GeneratedColumnsHelper.java:125)
      at org.apache.derbyTesting.functionTests.tests.lang.GeneratedColumnsTest.test_005_basicInsert(GeneratedColumnsTest.java:427)
      at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
      at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
      at org.apache.derbyTesting.junit.BaseTestCase.runBare(BaseTestCase.java:105)
      at junit.extensions.TestDecorator.basicRun(TestDecorator.java:22)
      at junit.extensions.TestSetup$1.protect(TestSetup.java:19)
      at junit.extensions.TestSetup.run(TestSetup.java:23)
      at org.apache.derbyTesting.junit.BaseTestSetup.run(BaseTestSetup.java:57)
      at junit.extensions.TestDecorator.basicRun(TestDecorator.java:22)
      at junit.extensions.TestSetup$1.protect(TestSetup.java:19)
      at junit.extensions.TestSetup.run(TestSetup.java:23)
      Caused by: java.sql.SQLException: Java exception: 'org/apache/derby/exe/acd83d18d1x0120x62bdx2dffxffffb19003081 0000 0000 : java.lang.VerifyError'.
      at java.lang.Throwable.<init>(Throwable.java:196)
      at java.lang.Exception.<init>(Exception.java:41)
      at java.sql.SQLException.<init>(SQLException.java:40)
      at org.apache.derby.impl.jdbc.EmbedSQLException.<init>(Unknown Source)
      at org.apache.derby.impl.jdbc.SQLExceptionFactory.getSQLException(Unknown Source)
      at org.apache.derby.impl.jdbc.Util.newEmbedSQLException(Unknown Source)
      at org.apache.derby.impl.jdbc.Util.javaException(Unknown Source)
      at org.apache.derby.impl.jdbc.TransactionResourceImpl.wrapInSQLException(Unknown Source)
      ... 43 more
      Caused by: java.lang.VerifyError: org/apache/derby/exe/acd83d18d1x0120x62bdx2dffxffffb19003081 0000 0000
      at java.lang.Throwable.<init>(Throwable.java:196)
      at java.lang.Error.<init>(Error.java:49)
      at java.lang.VerifyError.<init>(VerifyError.java:34)
      at sun.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:39)
      at sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:27)
      at java.lang.reflect.Constructor.newInstance(Constructor.java:494)
      at org.apache.derby.iapi.services.loader.ClassInfo.getNewInstance(Unknown Source)
      at org.apache.derby.impl.services.reflect.LoadedGeneratedClass.newInstance(Unknown Source)
      at org.apache.derby.impl.services.reflect.ReflectGeneratedClass.newInstance(Unknown Source)
      at org.apache.derby.impl.sql.GenericActivationHolder.<init>(Unknown Source)
      at org.apache.derby.impl.sql.GenericPreparedStatement.getActivation(Unknown Source)
      ... 39 more

      1. verify.out
        0.2 kB
        Myrna van Lunteren
      2. suitesall.out
        583 kB
        Myrna van Lunteren
      3. suites.all_10.5.1.2.789449_with_kahd4142.txt
        670 kB
        Kathey Marsden
      4. runjodedecompile.out
        5 kB
        Myrna van Lunteren
      5. repro.sql
        0.1 kB
        Kathey Marsden
      6. DERBY-4142.diff
        0.7 kB
        Myrna van Lunteren
      7. derby.properties
        0.0 kB
        Kathey Marsden
      8. decompile.out
        8 kB
        Myrna van Lunteren
      9. d4142-kah-noField.diff
        2 kB
        Knut Anders Hatlen
      10. d4142generated.java
        4 kB
        Myrna van Lunteren
      11. create.sql
        0.2 kB
        Kathey Marsden

        Issue Links

          Activity

          Gavin made changes -
          Workflow jira [ 12459834 ] Default workflow, editable Closed status [ 12800091 ]
          Myrna van Lunteren made changes -
          Status Resolved [ 5 ] Closed [ 6 ]
          Kathey Marsden made changes -
          Fix Version/s 10.5.2.0 [ 12314116 ]
          Fix Version/s 10.5.1.2 [ 12313870 ]
          Hide
          Kathey Marsden added a comment -

          Actually that first run I posted (suites.all_10.5.1.2.789449_with_kahd4142.txt) was with IBM 1.6.
          I ran again with IBM 1.5 and saw only known issues I think with InternationalConnectTest and some errors connecting to network server, but again no OutOfMemoryExceptions.

          Show
          Kathey Marsden added a comment - Actually that first run I posted (suites.all_10.5.1.2.789449_with_kahd4142.txt) was with IBM 1.6. I ran again with IBM 1.5 and saw only known issues I think with InternationalConnectTest and some errors connecting to network server, but again no OutOfMemoryExceptions.
          Kathey Marsden made changes -
          Status Open [ 1 ] Resolved [ 5 ]
          Fix Version/s 10.5.1.2 [ 12313870 ]
          Fix Version/s 10.6.0.0 [ 12313727 ]
          Resolution Fixed [ 1 ]
          Hide
          Kathey Marsden added a comment -

          Committed fixes to trunk and 10.5. Resolving this issue. Thanks Knut and Myrna for your work on this issue.

          Show
          Kathey Marsden added a comment - Committed fixes to trunk and 10.5. Resolving this issue. Thanks Knut and Myrna for your work on this issue.
          Kathey Marsden made changes -
          Hide
          Kathey Marsden added a comment -

          Attached are the results of my iseries run on 10.5 with d4142-kah-noField.diff patch and a sane build (suites.all_10.5.1.2.789449_with_kahd4142.txt). The tests that previously failed before the fix now pass and I did not see any OutOfMemoryErrors. I did see some lock timeouts and some grant/revoke errors that need investigation, but I don't think could be related to this patch, so I plan to go ahead and check this in later today if nobody objects.

          Show
          Kathey Marsden added a comment - Attached are the results of my iseries run on 10.5 with d4142-kah-noField.diff patch and a sane build (suites.all_10.5.1.2.789449_with_kahd4142.txt). The tests that previously failed before the fix now pass and I did not see any OutOfMemoryErrors. I did see some lock timeouts and some grant/revoke errors that need investigation, but I don't think could be related to this patch, so I plan to go ahead and check this in later today if nobody objects.
          Dag H. Wanvik made changes -
          Component/s Test [ 11413 ]
          Dag H. Wanvik made changes -
          Component/s Test [ 11413 ]
          Hide
          Myrna van Lunteren added a comment -

          Forgot to say - the OOM errors were on iseries - I ran suites.All and derbyall with the same build on Linux without any failures.

          Show
          Myrna van Lunteren added a comment - Forgot to say - the OOM errors were on iseries - I ran suites.All and derbyall with the same build on Linux without any failures.
          Myrna van Lunteren made changes -
          Assignee Myrna van Lunteren [ myrna ]
          Myrna van Lunteren made changes -
          Attachment suitesall.out [ 12410423 ]
          Hide
          Myrna van Lunteren added a comment -

          Attaching the suites.All result of the latest run - this is insane jars with Knut's patch.
          Unfortunately, I got numerous OOM errors and some 'cannot flush to disk' failures.
          They may well be unrelated to this issue, but I cannot look into this further until July 14.

          Show
          Myrna van Lunteren added a comment - Attaching the suites.All result of the latest run - this is insane jars with Knut's patch. Unfortunately, I got numerous OOM errors and some 'cannot flush to disk' failures. They may well be unrelated to this issue, but I cannot look into this further until July 14.
          Hide
          Myrna van Lunteren added a comment -

          Well, the hang in wisconsin occurred with the build on one of my environments, without changes, but not another. So I must have messed that tree up somehow.
          I'll try Knut's patch (in the environment that's good) and report back...

          Show
          Myrna van Lunteren added a comment - Well, the hang in wisconsin occurred with the build on one of my environments, without changes, but not another. So I must have messed that tree up somehow. I'll try Knut's patch (in the environment that's good) and report back...
          Hide
          Mamta A. Satoor added a comment - - edited

          I agree with Knut and prefer changing the return type Activation.getCurrentRow() to ExecRow since rest of the code is referencing to that object as ExecRow rather than just Row.

          also, I had to kill my suite test last night because the machine was getting really hot(not just because of this suite run, My machine has been heating up a lot lately). Have fired the tests again earlier this morning.If we decide to update the patch with the review comments, I will refire the tests.

          Show
          Mamta A. Satoor added a comment - - edited I agree with Knut and prefer changing the return type Activation.getCurrentRow() to ExecRow since rest of the code is referencing to that object as ExecRow rather than just Row. also, I had to kill my suite test last night because the machine was getting really hot(not just because of this suite run, My machine has been heating up a lot lately). Have fired the tests again earlier this morning.If we decide to update the patch with the review comments, I will refire the tests.
          Hide
          Knut Anders Hatlen added a comment -

          FWIW, all the regression tests ran cleanly on my machine with the patch that removes the problematic field.

          Show
          Knut Anders Hatlen added a comment - FWIW, all the regression tests ran cleanly on my machine with the patch that removes the problematic field.
          Knut Anders Hatlen made changes -
          Attachment d4142-kah-noField.diff [ 12410285 ]
          Hide
          Knut Anders Hatlen added a comment -

          The patch d4142-kah-noField.diff shows an (untested) alternative to changing the return type of the field. It simply removes the field and keeps the current row on the stack. A field is not needed since the current row doesn't need to survive between invocations of the method, so I think this simplification of the generated class would be good anyway.

          Show
          Knut Anders Hatlen added a comment - The patch d4142-kah-noField.diff shows an (untested) alternative to changing the return type of the field. It simply removes the field and keeps the current row on the stack. A field is not needed since the current row doesn't need to survive between invocations of the method, so I think this simplification of the generated class would be good anyway.
          Hide
          Knut Anders Hatlen added a comment -

          I think I would feel more comfortable with one of the solutions that
          avoided the cast. I agree with Mamta that the cast is safe, but making
          the signatures say explicitly that the method always returns an ExecRow
          sounds cleaner. Then we also get a compile-time check of the assumption,
          instead of just a run-time check as we get with the cast.

          Although the simplest way to fix it is to change the field to type Row
          (should be safe because it is only used to call Row.setColumn()), I
          think it would also make sense to change the return type of
          Activation.getCurrentRow() to ExecRow. That would make it consistent
          with Activation.setCurrentRow() which already is declared to take an
          ExecRow, and make it clear that the returned value is always an ExecRow.

          Show
          Knut Anders Hatlen added a comment - I think I would feel more comfortable with one of the solutions that avoided the cast. I agree with Mamta that the cast is safe, but making the signatures say explicitly that the method always returns an ExecRow sounds cleaner. Then we also get a compile-time check of the assumption, instead of just a run-time check as we get with the cast. Although the simplest way to fix it is to change the field to type Row (should be safe because it is only used to call Row.setColumn()), I think it would also make sense to change the return type of Activation.getCurrentRow() to ExecRow. That would make it consistent with Activation.setCurrentRow() which already is declared to take an ExecRow, and make it clear that the returned value is always an ExecRow.
          Hide
          Mamta A. Satoor added a comment -

          Myrna, I applied your patch on my client. I will run the tests on my Windows XP machine with ibm15. I know you are encountering the problem on iseries but I will run the tests just for basic sanity check.

          Show
          Mamta A. Satoor added a comment - Myrna, I applied your patch on my client. I will run the tests on my Windows XP machine with ibm15. I know you are encountering the problem on iseries but I will run the tests just for basic sanity check.
          Hide
          Myrna van Lunteren added a comment -

          Thanks for reviewing the patch Mamta!

          I've been trying to test a patched build with ibm 1.5. on iseries, but have run into trouble:

          • OOM with suites.All. I've been running with -Xmx1024M -Xms1024M before and that worked in the past...Not sure what's going on now. A second run (with 2048M) only got worse (sooner) OOM behavior and after that I had trouble getting rid of my processes
          • apparent hang with derbyall:lang/wisconsin.java. I have stupidly deleted the original test dir, but judging from the suite's output files, no output was created after 3 1/2 hours. On rerun I let it go for 20 mins, but apart from the database getting booted (derby.log) nothing at all showed up in any of the output files (i.e. .tmp was empty). During the 10.5.1.1 test cycle this test took about 5 mins (and passed).

          So, the original problem appears addressed (as I said, the 3 failing tests now pass), but I will investigate these behaviors, and run on another type of machine just to be safe.

          Show
          Myrna van Lunteren added a comment - Thanks for reviewing the patch Mamta! I've been trying to test a patched build with ibm 1.5. on iseries, but have run into trouble: OOM with suites.All. I've been running with -Xmx1024M -Xms1024M before and that worked in the past...Not sure what's going on now. A second run (with 2048M) only got worse (sooner) OOM behavior and after that I had trouble getting rid of my processes apparent hang with derbyall:lang/wisconsin.java. I have stupidly deleted the original test dir, but judging from the suite's output files, no output was created after 3 1/2 hours. On rerun I let it go for 20 mins, but apart from the database getting booted (derby.log) nothing at all showed up in any of the output files (i.e. .tmp was empty). During the 10.5.1.1 test cycle this test took about 5 mins (and passed). So, the original problem appears addressed (as I said, the 3 failing tests now pass), but I will investigate these behaviors, and run on another type of machine just to be safe.
          Hide
          Mamta A. Satoor added a comment -

          Myrna, I looked through the code more and I think we are safe to do the CASTing to ExecRow. Even though, iapi.sql.Activation interface has following method declaration
          public Row getCurrentRow(int resultSetNumber);
          The actual implementation of the method in impl.sql.execute.BaseActivation has following code
          public Row getCurrentRow(int resultSetNumber)

          { return row[resultSetNumber]; }

          Note that the row arrary has been defined as an array of "ExecRow" rather than "Row". I think this row arrary gets filled by implementation classes of interface CursorResultSet with following method
          ExecRow getCurrentRow() throws StandardException;
          Agin, notice that the method is defined to return ExecRow.

          So, in short, I think we are ok CASTing Row to ExecRow in the generated code.

          Show
          Mamta A. Satoor added a comment - Myrna, I looked through the code more and I think we are safe to do the CASTing to ExecRow. Even though, iapi.sql.Activation interface has following method declaration public Row getCurrentRow(int resultSetNumber); The actual implementation of the method in impl.sql.execute.BaseActivation has following code public Row getCurrentRow(int resultSetNumber) { return row[resultSetNumber]; } Note that the row arrary has been defined as an array of "ExecRow" rather than "Row". I think this row arrary gets filled by implementation classes of interface CursorResultSet with following method ExecRow getCurrentRow() throws StandardException; Agin, notice that the method is defined to return ExecRow. So, in short, I think we are ok CASTing Row to ExecRow in the generated code.
          Hide
          Mamta A. Satoor added a comment -

          Myrna, I reviewed the patch. As for whether getCurrentRow() always return an ExecRow in this case, I am not sure about that. I will look further into the code to see if we can make that assumption. Otherwise, we probably should change the signature to declare the field as a Row instead of ExecRow.

          Show
          Mamta A. Satoor added a comment - Myrna, I reviewed the patch. As for whether getCurrentRow() always return an ExecRow in this case, I am not sure about that. I will look further into the code to see if we can make that assumption. Otherwise, we probably should change the signature to declare the field as a Row instead of ExecRow.
          Mike Matrigali made changes -
          Component/s SQL [ 11408 ]
          Hide
          Kathey Marsden added a comment -

          Linking to DERBY-481 (implement SQL generated columns) where this issue was introduced.

          Show
          Kathey Marsden added a comment - Linking to DERBY-481 (implement SQL generated columns) where this issue was introduced.
          Kathey Marsden made changes -
          Link This issue is related to DERBY-481 [ DERBY-481 ]
          Myrna van Lunteren made changes -
          Derby Info [Patch Available]
          Myrna van Lunteren made changes -
          Assignee Myrna van Lunteren [ myrna ]
          Myrna van Lunteren made changes -
          Attachment DERBY-4142.diff [ 12409914 ]
          Hide
          Myrna van Lunteren added a comment -

          Attaching a patch for this issue - just causing a cast of the 'Row' resulting in the generated columns code in DMLModStatementNode.java to ExecRow.

          The tests lang/autoincrement.sql and junit tests lang.GeneratedColumnsTest and lang.GeneratedColumnsPermsTest pass with this patch with ibm15 on iseries. I'll run derbyall and suites.All now.

          I would appreciate a review, for there's some questions:

          • Will getCurrentRow() always return an ExecRow in this case?
          • Would it be better instead to declare the field as a Row instead of an ExecRow?
          Show
          Myrna van Lunteren added a comment - Attaching a patch for this issue - just causing a cast of the 'Row' resulting in the generated columns code in DMLModStatementNode.java to ExecRow. The tests lang/autoincrement.sql and junit tests lang.GeneratedColumnsTest and lang.GeneratedColumnsPermsTest pass with this patch with ibm15 on iseries. I'll run derbyall and suites.All now. I would appreciate a review, for there's some questions: Will getCurrentRow() always return an ExecRow in this case? Would it be better instead to declare the field as a Row instead of an ExecRow?
          Myrna van Lunteren made changes -
          Attachment runjodedecompile.out [ 12409893 ]
          Attachment d4142generated.java [ 12409894 ]
          Hide
          Myrna van Lunteren added a comment - - edited

          I'm attaching the decompile result of the decompile with jode (as Rick had said he's had good results it seemed worthwhile trying it out).
          I then turned the class into d4142generated.java (to simplify the name, also attached) and then compiled that class with javac.
          This gives:

          d4142generated.java:100: e2() in org.apache.derby.exe.d4142generated cannot implement e2() in org.apache.derby.iapi.services.loader.GeneratedByteCode; overridden method does not throw java.lang.Exception
          public Object e2() throws StandardException, Exception {
          ^
          d4142generated.java:81: e1() in org.apache.derby.exe.d4142generated cannot implement e1() in org.apache.derby.iapi.services.loader.GeneratedByteCode; overridden method does not throw java.lang.Exception
          public Object e1() throws StandardException, Exception {
          ^
          d4142generated.java:77: e0() in org.apache.derby.exe.d4142generated cannot implement e0() in org.apache.derby.iapi.services.loader.GeneratedByteCode; overridden method does not throw java.lang.Exception
          public Object e0() throws StandardException, Exception {
          ^
          d4142generated.java:86: incompatible types
          found : org.apache.derby.iapi.sql.Row
          required: org.apache.derby.iapi.sql.execute.ExecRow
          = /TYPE_ERROR/ row;
          ^

          I suspect the last one is our problem, and will work to fix that issue first.

          Show
          Myrna van Lunteren added a comment - - edited I'm attaching the decompile result of the decompile with jode (as Rick had said he's had good results it seemed worthwhile trying it out). I then turned the class into d4142generated.java (to simplify the name, also attached) and then compiled that class with javac. This gives: d4142generated.java:100: e2() in org.apache.derby.exe.d4142generated cannot implement e2() in org.apache.derby.iapi.services.loader.GeneratedByteCode; overridden method does not throw java.lang.Exception public Object e2() throws StandardException, Exception { ^ d4142generated.java:81: e1() in org.apache.derby.exe.d4142generated cannot implement e1() in org.apache.derby.iapi.services.loader.GeneratedByteCode; overridden method does not throw java.lang.Exception public Object e1() throws StandardException, Exception { ^ d4142generated.java:77: e0() in org.apache.derby.exe.d4142generated cannot implement e0() in org.apache.derby.iapi.services.loader.GeneratedByteCode; overridden method does not throw java.lang.Exception public Object e0() throws StandardException, Exception { ^ d4142generated.java:86: incompatible types found : org.apache.derby.iapi.sql.Row required: org.apache.derby.iapi.sql.execute.ExecRow = / TYPE_ERROR / row; ^ I suspect the last one is our problem, and will work to fix that issue first.
          Hide
          Myrna van Lunteren added a comment -

          no, simple typo in the class name. I deleted that one and uploaded one done with the correct file name (cut-and-paste didn't do it for me either). But I'm not sure the actual result isn't very useful after all.

          Show
          Myrna van Lunteren added a comment - no, simple typo in the class name. I deleted that one and uploaded one done with the correct file name (cut-and-paste didn't do it for me either). But I'm not sure the actual result isn't very useful after all.
          Hide
          Kathey Marsden added a comment -

          Teh verify output just has a java.lang.NoClassDefFoundError. Maybe a classpath issue?

          Show
          Kathey Marsden added a comment - Teh verify output just has a java.lang.NoClassDefFoundError. Maybe a classpath issue?
          Myrna van Lunteren made changes -
          Attachment verify.out [ 12409314 ]
          Hide
          Myrna van Lunteren added a comment -

          downloaded wrong file

          Show
          Myrna van Lunteren added a comment - downloaded wrong file
          Myrna van Lunteren made changes -
          Attachment verify.out [ 12409313 ]
          Myrna van Lunteren made changes -
          Attachment decompile.out [ 12409312 ]
          Attachment verify.out [ 12409313 ]
          Hide
          Myrna van Lunteren added a comment -

          Attaching the result of the decompile and verify step.

          Show
          Myrna van Lunteren added a comment - Attaching the result of the decompile and verify step.
          Kathey Marsden made changes -
          Attachment repro.sql [ 12409215 ]
          Attachment create.sql [ 12409216 ]
          Attachment derby.properties [ 12409217 ]
          Hide
          Kathey Marsden added a comment -

          Based on the stack trace, hopefully this will reproduce the issue. Run create.sql to create the database and then repro.sql with the derby.properties attached.

          Show
          Kathey Marsden added a comment - Based on the stack trace, hopefully this will reproduce the issue. Run create.sql to create the database and then repro.sql with the derby.properties attached.
          Myrna van Lunteren made changes -
          Affects Version/s 10.5.1.0 [ 12313770 ]
          Myrna van Lunteren made changes -
          Field Original Value New Value
          Affects Version/s 10.5.1.1 [ 12313771 ]
          Hide
          Bryan Pendleton added a comment -

          I think that http://wiki.apache.org/db-derby/DumpClassFile may be the wiki page you were
          remembering. The instructions on that page are pretty close to the instructions given here;
          I'll add some additional notes about javap and about jode.

          Show
          Bryan Pendleton added a comment - I think that http://wiki.apache.org/db-derby/DumpClassFile may be the wiki page you were remembering. The instructions on that page are pretty close to the instructions given here; I'll add some additional notes about javap and about jode.
          Hide
          Rick Hillegas added a comment -

          I have had good success decompiling the generated code by using the free Jode decompiler. I find that Jode succeeds where most decompilers fail. In addition, I have found that the decompiled code is easy to read and can be compiled into byte code again. Not all decompilers produce compilable code. Here is the script which I use to drive Jode:

          #! /bin/bash
          #

          1. Run the jode decompiler on a class. E.g.:
            #
          2. runjode acf81e0010x011cxddd8xfcabx0000000feab00

          classStub=$1

          . setupClasspath

          export CLASSPATH=$CLASSPATH:$SW/javaDecompilers/jode/jode-1.1.2-pre1.jar:.

          echo $CLASSPATH

          mkdir org
          mkdir org/apache
          mkdir org/apache/derby
          mkdir org/apache/derby/exe

          cp $classStub.class org/apache/derby/exe/

          #java -cp $CLASSPATH jode.decompiler.Main --help $*
          java -cp $CLASSPATH jode.decompiler.Main org.apache.derby.exe.$classStub

          Show
          Rick Hillegas added a comment - I have had good success decompiling the generated code by using the free Jode decompiler. I find that Jode succeeds where most decompilers fail. In addition, I have found that the decompiled code is easy to read and can be compiled into byte code again. Not all decompilers produce compilable code. Here is the script which I use to drive Jode: #! /bin/bash # Run the jode decompiler on a class. E.g.: # runjode acf81e0010x011cxddd8xfcabx0000000feab00 classStub=$1 . setupClasspath export CLASSPATH=$CLASSPATH:$SW/javaDecompilers/jode/jode-1.1.2-pre1.jar:. echo $CLASSPATH mkdir org mkdir org/apache mkdir org/apache/derby mkdir org/apache/derby/exe cp $classStub.class org/apache/derby/exe/ #java -cp $CLASSPATH jode.decompiler.Main --help $* java -cp $CLASSPATH jode.decompiler.Main org.apache.derby.exe.$classStub
          Hide
          Kathey Marsden added a comment -

          Myrna asked me to post some poiters on tracking down this issue.
          I thought we had a Wiki page on debugging generated code issues, but I don't see it, so here are some pointers on getting started as I remember them.
          1) Try to reduce the issue down to a single statement.
          2) Put derby.debug.true=DumpClassFile in your derby.properties
          3) Run the statement and you will get a class file (e.g. ac12564092x0120xa5a3x8f46x000.class)
          4) Put . in your classpath.
          5) move the class file to a directory org/apache/derby/exe
          6) Use javap -c org.apache.derby.exe.ac12564092x0120xa5a3x8f46x000 to decompile the class
          7) Use java -verify org.apache.derby.exe.ac12564092x0120xa5a3x8f46x000 to perhaps get more information on verification of the class.

          As I recall the javap -c step croaks at the point where their is an issue, but I am not sure about that.
          But let's say your problem is in setRowCountCheckVector. You then want to do a search of the code of that string in quotes and you will find the place where the code is generated. Once you find that, post and we will look further.

          Show
          Kathey Marsden added a comment - Myrna asked me to post some poiters on tracking down this issue. I thought we had a Wiki page on debugging generated code issues, but I don't see it, so here are some pointers on getting started as I remember them. 1) Try to reduce the issue down to a single statement. 2) Put derby.debug.true=DumpClassFile in your derby.properties 3) Run the statement and you will get a class file (e.g. ac12564092x0120xa5a3x8f46x000.class) 4) Put . in your classpath. 5) move the class file to a directory org/apache/derby/exe 6) Use javap -c org.apache.derby.exe.ac12564092x0120xa5a3x8f46x000 to decompile the class 7) Use java -verify org.apache.derby.exe.ac12564092x0120xa5a3x8f46x000 to perhaps get more information on verification of the class. As I recall the javap -c step croaks at the point where their is an issue, but I am not sure about that. But let's say your problem is in setRowCountCheckVector. You then want to do a search of the code of that string in quotes and you will find the place where the code is generated. Once you find that, post and we will look further.
          Hide
          Myrna van Lunteren added a comment -

          Note that although this is likely a Derby issue, the IBM 1.6 SR3 does not show a java.lang.VerifyError.

          Show
          Myrna van Lunteren added a comment - Note that although this is likely a Derby issue, the IBM 1.6 SR3 does not show a java.lang.VerifyError.
          Hide
          Myrna van Lunteren added a comment -

          Also lang/autoincrement.sql fails in this manner:
          2095a2096,2102
          > ERROR XBCM2: Cannot create an instance of generated class org.apache.derby.exe
          .ac363c44a2x0120x7f2cx914fxffffb5b8e96142.
          > ERROR XJ001: Java exception: 'org/apache/derby/exe/ac363c44a2x0120x7f2cx914fxf
          fffb5b8e96142 0000 0000 : java.lang.VerifyError'.
          > ij(CONN2)> alter table d4006 alter column y default 42;
          > ERROR 42X14: 'Y' is not a column in table or VTI 'D4006'.
          > ij(CONN2)> alter table d4006 alter column y default null;
          > ERROR 42X14: 'Y' is not a column in table or VTI 'D4006'.
          > ij(CONN2)> drop table d4006;
          2097,2102d2103
          < ij(CONN2)> alter table d4006 alter column y default 42;
          < ERROR 42XA7: 'Y' is a generated column. You cannot change its default value.
          < ij(CONN2)> alter table d4006 alter column y default null;
          < ERROR 42XA7: 'Y' is a generated column. You cannot change its default value.
          < ij(CONN2)> drop table d4006;
          < 0 rows inserted/updated/deleted

          Show
          Myrna van Lunteren added a comment - Also lang/autoincrement.sql fails in this manner: 2095a2096,2102 > ERROR XBCM2: Cannot create an instance of generated class org.apache.derby.exe .ac363c44a2x0120x7f2cx914fxffffb5b8e96142. > ERROR XJ001: Java exception: 'org/apache/derby/exe/ac363c44a2x0120x7f2cx914fxf fffb5b8e96142 0000 0000 : java.lang.VerifyError'. > ij(CONN2)> alter table d4006 alter column y default 42; > ERROR 42X14: 'Y' is not a column in table or VTI 'D4006'. > ij(CONN2)> alter table d4006 alter column y default null; > ERROR 42X14: 'Y' is not a column in table or VTI 'D4006'. > ij(CONN2)> drop table d4006; 2097,2102d2103 < ij(CONN2)> alter table d4006 alter column y default 42; < ERROR 42XA7: 'Y' is a generated column. You cannot change its default value. < ij(CONN2)> alter table d4006 alter column y default null; < ERROR 42XA7: 'Y' is a generated column. You cannot change its default value. < ij(CONN2)> drop table d4006; < 0 rows inserted/updated/deleted
          Hide
          Kathey Marsden added a comment -

          I don't know if this is relevant in this case as I have not checked the code, but we have found in the past that the iseries verifier is more strict than other JVM's, while still being correct. See DERBY-488 for an example of this. Since GeneratedColumns is a new feature, it may have a similar error in the code we generate.

          Show
          Kathey Marsden added a comment - I don't know if this is relevant in this case as I have not checked the code, but we have found in the past that the iseries verifier is more strict than other JVM's, while still being correct. See DERBY-488 for an example of this. Since GeneratedColumns is a new feature, it may have a similar error in the code we generate.
          Myrna van Lunteren created issue -

            People

            • Assignee:
              Unassigned
              Reporter:
              Myrna van Lunteren
            • Votes:
              0 Vote for this issue
              Watchers:
              0 Start watching this issue

              Dates

              • Created:
                Updated:
                Resolved:

                Development