|
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 Note that although this is likely a Derby issue, the IBM 1.6 SR3 does not show a java.lang.VerifyError.
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. 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 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.
Myrna van Lunteren made changes - 16/Apr/09 11:39 PM
Myrna van Lunteren made changes - 04/May/09 06:24 PM
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.
Kathey Marsden made changes - 27/May/09 09:53 PM
Attaching the result of the decompile and verify step.
Myrna van Lunteren made changes - 28/May/09 10:13 PM
Myrna van Lunteren made changes - 28/May/09 10:25 PM
downloaded wrong file
Myrna van Lunteren made changes - 28/May/09 10:26 PM
Teh verify output just has a java.lang.NoClassDefFoundError. Maybe a classpath issue?
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.
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.
Myrna van Lunteren made changes - 04/Jun/09 04:54 PM
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 - 04/Jun/09 10:56 PM
Myrna van Lunteren made changes - 04/Jun/09 10:56 PM
Myrna van Lunteren made changes - 04/Jun/09 10:56 PM
Kathey Marsden made changes - 04/Jun/09 11:46 PM
Linking to
Mike Matrigali made changes - 09/Jun/09 07:20 PM
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.
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. 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. 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.
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. 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.
Knut Anders Hatlen made changes - 10/Jun/09 07:30 AM
FWIW, all the regression tests ran cleanly on my machine with the patch that removes the problematic field.
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. 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... 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.
Myrna van Lunteren made changes - 11/Jun/09 07:09 PM
Myrna van Lunteren made changes - 11/Jun/09 07:09 PM
Forgot to say - the OOM errors were on iseries - I ran suites.All and derbyall with the same build on Linux without any failures.
Dag H. Wanvik made changes - 29/Jun/09 11:20 PM
Dag H. Wanvik made changes - 30/Jun/09 01:13 PM
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.
Kathey Marsden made changes - 30/Jun/09 02:40 PM
Committed fixes to trunk and 10.5. Resolving this issue. Thanks Knut and Myrna for your work on this issue.
Kathey Marsden made changes - 30/Jun/09 07:05 PM
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 - 16/Jul/09 09:24 PM
|
|||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
 |
|
Bug
Resolved
Major
java.lang.VerifyError causing java.sql.SQLException: Cannot create an instance of generated class ... in lang.GeneratedColumnsTest and GeneratedColumnsPermsTest on IBM iseries
DERBY-488for an example of this. Since GeneratedColumns is a new feature, it may have a similar error in the code we generate.