You are viewing a plain text version of this content. The canonical link for it is here.
Posted to derby-dev@db.apache.org by Mamta Satoor <ms...@gmail.com> on 2007/05/14 21:57:56 UTC
DERBY-1478 subtask DERBY-2583 - need help in debugging stack trace thrown during code generation
Hi,
I checked in code on April 24th revision 532082 for DERBY-2583 "At code
generation time, look at collation type to determine what kind of DVD should
get generated for character types."
The intention of the commit was to generate following
StringDataValueObject.getValue(DataValueFactory.getCharacterCollator(collationType));
This code generation change went in
BaseTypeCompiler.generateCollationSensitiveDataValue and it looked as
follows
protected void generateCollationSensitiveDataValue(MethodBuilder mb,
int collationType, String className){
if (collationType == StringDataValue.COLLATION_TYPE_UCS_BASIC)
return;
//In case of character DVDs, for territory based collation, we need to
//generate DVDs with territory based RuleBasedCollator and hence we
//need to generate CollatorSQLChar/CollatorSQLVarchar/
//CollatorSQLLongvarchar/CollatorSQLClob
pushDataValueFactory(mb, className);
mb.push(collationType);
mb.callMethod(VMOpcode.INVOKEINTERFACE, null, "getCharacterCollator",
"java.text.RuleBasedCollator", 1);
mb.callMethod(VMOpcode.INVOKEINTERFACE, null, "getValue", interfaceName(),
1);
}
This new api gets called by CharTypeCompiler and CLOBTypeCompiler as shown
below
generateDataValue(MethodBuilder, int, String, LocalField) -
org.apache.derby.impl.sql.compile.CharTypeCompiler
generateNull(MethodBuilder, int, String) -
org.apache.derby.impl.sql.compile.CharTypeCompiler
generateNull(MethodBuilder, int, String) -
org.apache.derby.impl.sql.compile.CLOBTypeCompiler
generateDataValue(MethodBuilder, int, String, LocalField) -
org.apache.derby.impl.sql.compile.CLOBTypeCompiler
When this new api is called, StringDataValue is already on the stack for
code generation. And the new code just uses that StringDataValue to generate
the additional code of StringDataValueObject.getValue(
DataValueFactory.getCharacterCollator(collationType)); and this new code
generation leaves a StringDataValue on the stack. So this new api used up
the StringDataValue on the stack and left another StringDataValue in it's
place.
Now that we have the background information, let me talk about the problem
at hand. When following piece of sql is executed inside a collated db, it
causes a stack trace
connect
'jdbc:derby:c:/dellater/db1_52_data;create=true;territory=no_no;collation=TERRITORY_BASED';
create table localize1(nc10 char(10));
insert into localize1 values ('a');
select nc10 from localize1;
The stack trace looks as follows
ERROR XJ001: Java exception: ': java.lang.ClassCastException'.
java.sql.SQLException: Java exception: ': java.lang.ClassCastException'.
at org.apache.derby.impl.jdbc.SQLExceptionFactory.getSQLException(
SQLExceptionFactory.java:45)
at org.apache.derby.impl.jdbc.Util.newEmbedSQLException(Util.java
:88)
at org.apache.derby.impl.jdbc.Util.newEmbedSQLException(Util.java
:99)
at org.apache.derby.impl.jdbc.Util.javaException(Util.java:234)
at
org.apache.derby.impl.jdbc.TransactionResourceImpl.wrapInSQLException(
TransactionResourceImpl.java:386)
at
org.apache.derby.impl.jdbc.TransactionResourceImpl.handleException(
TransactionResourceImpl.java:345)
at org.apache.derby.impl.jdbc.EmbedConnection.handleException(
EmbedConnection.java:1533)
at org.apache.derby.impl.jdbc.ConnectionChild.handleException(
ConnectionChild.java:81)
at org.apache.derby.impl.jdbc.EmbedStatement.execute(
EmbedStatement.java:573)
at org.apache.derby.impl.jdbc.EmbedStatement.execute(
EmbedStatement.java:516)
at org.apache.derby.impl.tools.ij.ij.executeImmediate(ij.java:330)
at org.apache.derby.impl.tools.ij.utilMain.doCatch(utilMain.java
:531)
at org.apache.derby.impl.tools.ij.utilMain.runScriptGuts(
utilMain.java:373)
at org.apache.derby.impl.tools.ij.utilMain.go(utilMain.java:271)
at org.apache.derby.impl.tools.ij.Main.go(Main.java:215)
at org.apache.derby.impl.tools.ij.Main.mainCore(Main.java:181)
at org.apache.derby.impl.tools.ij.Main14.main(Main14.java:56)
at org.apache.derby.tools.ij.main(ij.java:71)
Caused by: java.lang.ClassCastException
at
org.apache.derby.impl.services.bytecode.CodeChunk.getTypeDescriptor(
CodeChunk.java:1007)
at
org.apache.derby.impl.services.bytecode.CodeChunk.getVariableStackDelta(
CodeChunk.java:1059)
at org.apache.derby.impl.services.bytecode.CodeChunk.stackWordDelta(
CodeChunk.java:992)
at org.apache.derby.impl.services.bytecode.CodeChunk.findMaxStack(
CodeChunk.java:954)
at org.apache.derby.impl.services.bytecode.CodeChunk.complete(
CodeChunk.java:810)
at org.apache.derby.impl.services.bytecode.BCMethod.complete(
BCMethod.java:241)
at
org.apache.derby.impl.sql.compile.ResultColumnList.generateHolderMethod(
ResultColumnList.java:1477)
at org.apache.derby.impl.sql.compile.FromBaseTable.getScanArguments(
FromBaseTable.java:3399)
at org.apache.derby.impl.sql.compile.FromBaseTable.generateResultSet
(FromBaseTable.java:3135)
at org.apache.derby.impl.sql.compile.FromBaseTable.generate(
FromBaseTable.java:3062)
at
org.apache.derby.impl.sql.compile.ProjectRestrictNode.generateMinion(
ProjectRestrictNode.java:1351)
at org.apache.derby.impl.sql.compile.ProjectRestrictNode.generate(
ProjectRestrictNode.java:1302)
at
org.apache.derby.impl.sql.compile.ProjectRestrictNode.generateMinion(
ProjectRestrictNode.java:1351)
at org.apache.derby.impl.sql.compile.ProjectRestrictNode.generate(
ProjectRestrictNode.java:1302)
at
org.apache.derby.impl.sql.compile.ScrollInsensitiveResultSetNode.generate(
ScrollInsensitiveResultSetNode.java:109)
at org.apache.derby.impl.sql.compile.CursorNode.generate(
CursorNode.java:564)
at org.apache.derby.impl.sql.compile.StatementNode.generate(
StatementNode.java:347)
at org.apache.derby.impl.sql.GenericStatement.prepMinion(
GenericStatement.java:447)
at org.apache.derby.impl.sql.GenericStatement.prepare(
GenericStatement.java:88)
at
org.apache.derby.impl.sql.conn.GenericLanguageConnectionContext.prepareInternalStatement
(GenericLanguageConnectionContext.java:742)
at org.apache.derby.impl.jdbc.EmbedStatement.execute(
EmbedStatement.java:567)
... 9 more
Looking at stack trace, it looks like something is wrong in maybe my code
generation changes and wondered if someone familiar with code generation can
tell me what I am doing wrong. I will keep debugging but any help will be
greatly appreciated.
thanks,
Mamta
Re: DERBY-1478 subtask DERBY-2583 - need help in debugging stack
trace thrown during code generation
Posted by Mike Matrigali <mi...@sbcglobal.net>.
Mamta Satoor wrote:
> Hi,
>
> I checked in code on April 24th revision 532082 for DERBY-2583 "At code
> generation time, look at collation type to determine what kind of DVD
> should get generated for character types."
>
> The intention of the commit was to generate following
> StringDataValueObject.getValue(DataValueFactory.getCharacterCollator(collationType));
>
>
> This code generation change went in
> BaseTypeCompiler.generateCollationSensitiveDataValue and it looked as
> follows
> protected void generateCollationSensitiveDataValue(MethodBuilder mb,
> int collationType, String className){
> if (collationType == StringDataValue.COLLATION_TYPE_UCS_BASIC)
> return;
> //In case of character DVDs, for territory based collation, we need to
> //generate DVDs with territory based RuleBasedCollator and hence we
> //need to generate CollatorSQLChar/CollatorSQLVarchar/
> //CollatorSQLLongvarchar/CollatorSQLClob
> pushDataValueFactory(mb, className);
> mb.push(collationType);
> mb.callMethod(VMOpcode.INVOKEINTERFACE , null, "getCharacterCollator",
> "java.text.RuleBasedCollator", 1);
> mb.callMethod(VMOpcode.INVOKEINTERFACE, null, "getValue",
> interfaceName(), 1);
> }
> This new api gets called by CharTypeCompiler and CLOBTypeCompiler as
> shown below
> generateDataValue(MethodBuilder, int, String, LocalField) -
> org.apache.derby.impl.sql.compile.CharTypeCompiler
> generateNull(MethodBuilder, int, String) -
> org.apache.derby.impl.sql.compile.CharTypeCompiler
> generateNull(MethodBuilder, int, String) -
> org.apache.derby.impl.sql.compile.CLOBTypeCompiler
> generateDataValue(MethodBuilder, int, String, LocalField) -
> org.apache.derby.impl.sql.compile.CLOBTypeCompiler
>
>
> When this new api is called, StringDataValue is already on the stack for
> code generation. And the new code just uses that StringDataValue to
> generate the additional code of
> StringDataValueObject.getValue(DataValueFactory.getCharacterCollator
> (collationType)); and this new code generation leaves a StringDataValue
> on the stack. So this new api used up the StringDataValue on the stack
> and left another StringDataValue in it's place.
>
> Now that we have the background information, let me talk about the
> problem at hand. When following piece of sql is executed inside a
> collated db, it causes a stack trace
> connect
> 'jdbc:derby:c:/dellater/db1_52_data;create=true;territory=no_no;collation=TERRITORY_BASED';
>
> create table localize1(nc10 char(10));
> insert into localize1 values ('a');
> select nc10 from localize1;
>
> The stack trace looks as follows
> ERROR XJ001: Java exception: ': java.lang.ClassCastException'.
> java.sql.SQLException: Java exception: ': java.lang.ClassCastException'.
> at org.apache.derby.impl.jdbc.SQLExceptionFactory.getSQLException
> (SQLExceptionFactory.java:45)
> at
> org.apache.derby.impl.jdbc.Util.newEmbedSQLException(Util.java:88)
> at
> org.apache.derby.impl.jdbc.Util.newEmbedSQLException(Util.java:99)
> at org.apache.derby.impl.jdbc.Util.javaException (Util.java:234)
> at
> org.apache.derby.impl.jdbc.TransactionResourceImpl.wrapInSQLException(TransactionResourceImpl.java:386)
> at
> org.apache.derby.impl.jdbc.TransactionResourceImpl.handleException(TransactionResourceImpl.java
> :345)
> at
> org.apache.derby.impl.jdbc.EmbedConnection.handleException(EmbedConnection.java:1533)
> at
> org.apache.derby.impl.jdbc.ConnectionChild.handleException(ConnectionChild.java:81)
> at org.apache.derby.impl.jdbc.EmbedStatement.execute
> (EmbedStatement.java:573)
> at
> org.apache.derby.impl.jdbc.EmbedStatement.execute(EmbedStatement.java:516)
> at org.apache.derby.impl.tools.ij.ij.executeImmediate(ij.java:330)
> at org.apache.derby.impl.tools.ij.utilMain.doCatch
> (utilMain.java:531)
> at
> org.apache.derby.impl.tools.ij.utilMain.runScriptGuts(utilMain.java:373)
> at org.apache.derby.impl.tools.ij.utilMain.go(utilMain.java:271)
> at org.apache.derby.impl.tools.ij.Main.go (Main.java:215)
> at org.apache.derby.impl.tools.ij.Main.mainCore(Main.java:181)
> at org.apache.derby.impl.tools.ij.Main14.main(Main14.java:56)
> at org.apache.derby.tools.ij.main(ij.java:71)
> Caused by: java.lang.ClassCastException
> at
> org.apache.derby.impl.services.bytecode.CodeChunk.getTypeDescriptor(CodeChunk.java:1007)
> at
> org.apache.derby.impl.services.bytecode.CodeChunk.getVariableStackDelta
> (CodeChunk.java:1059)
> at
> org.apache.derby.impl.services.bytecode.CodeChunk.stackWordDelta(CodeChunk.java:992)
> at
> org.apache.derby.impl.services.bytecode.CodeChunk.findMaxStack(CodeChunk.java:954)
> at
> org.apache.derby.impl.services.bytecode.CodeChunk.complete(CodeChunk.java:810)
> at
> org.apache.derby.impl.services.bytecode.BCMethod.complete(BCMethod.java:241)
> at
> org.apache.derby.impl.sql.compile.ResultColumnList.generateHolderMethod
> (ResultColumnList.java:1477)
> at
> org.apache.derby.impl.sql.compile.FromBaseTable.getScanArguments(FromBaseTable.java:3399)
> at
> org.apache.derby.impl.sql.compile.FromBaseTable.generateResultSet(FromBaseTable.java
> :3135)
> at
> org.apache.derby.impl.sql.compile.FromBaseTable.generate(FromBaseTable.java:3062)
> at
> org.apache.derby.impl.sql.compile.ProjectRestrictNode.generateMinion(ProjectRestrictNode.java:1351)
> at
> org.apache.derby.impl.sql.compile.ProjectRestrictNode.generate(ProjectRestrictNode.java:1302)
> at
> org.apache.derby.impl.sql.compile.ProjectRestrictNode.generateMinion(ProjectRestrictNode.java:1351)
> at
> org.apache.derby.impl.sql.compile.ProjectRestrictNode.generate(ProjectRestrictNode.java:1302)
> at
> org.apache.derby.impl.sql.compile.ScrollInsensitiveResultSetNode.generate(ScrollInsensitiveResultSetNode.java:109)
>
> at
> org.apache.derby.impl.sql.compile.CursorNode.generate(CursorNode.java:564)
> at
> org.apache.derby.impl.sql.compile.StatementNode.generate(StatementNode.java:347)
> at org.apache.derby.impl.sql.GenericStatement.prepMinion
> (GenericStatement.java:447)
> at
> org.apache.derby.impl.sql.GenericStatement.prepare(GenericStatement.java:88)
> at
> org.apache.derby.impl.sql.conn.GenericLanguageConnectionContext.prepareInternalStatement
> (GenericLanguageConnectionContext.java:742)
> at
> org.apache.derby.impl.jdbc.EmbedStatement.execute(EmbedStatement.java:567)
> ... 9 more
>
The stack I got from ibm15 gave a little more info - though may be for a
different bug, it is from some tests I have not checked in. It gives
the names of the 2 classes:
ATABASE = singleUse/oneuse1), (DRDAID = null), Failed Statement is:
UPDATE CUSTO
MER SET NAME = D1^M
java.lang.ClassCastException:
org.apache.derby.iapi.services.classfile.CONSTANT_Utf8_info incompatible
with org.apache.derby.iapi.services.classfile.CONSTANT_Index_info^M
at
org.apache.derby.impl.services.bytecode.CodeChunk.getTypeDescriptor(CodeC
hunk.java:1011)^M
at
org.apache.derby.impl.services.bytecode.CodeChunk.getVariableStackDelta(C
odeChunk.java:1059)^M
at
org.apache.derby.impl.services.bytecode.CodeChunk.stackWordDelta(CodeChun
k.java:992)^M
at
org.apache.derby.impl.services.bytecode.CodeChunk.findMaxStack(CodeChunk.
java:954)^M
at
org.apache.derby.impl.services.bytecode.CodeChunk.complete(CodeChunk.java
:810)^M
at
org.apache.derby.impl.services.bytecode.BCMethod.complete(BCMethod.java:2
41)^M
at
org.apache.derby.impl.sql.compile.ResultColumnList.generateHolderMethod(R
esultColumnList.java:1477)^M
at
org.apache.derby.impl.sql.compile.FromBaseTable.getScanArguments(FromBase
Table.java:3399)^M
at
org.apache.derby.impl.sql.compile.FromBaseTable.generateResultSet(FromBas
eTable.java:3135)^M
at
org.apache.derby.impl.sql.compile.FromBaseTable.generate(FromBaseTable.ja
va:3062)^M
at
org.apache.derby.impl.sql.compile.ProjectRestrictNode.generateMinion(Proj
ectRestrictNode.java:1351)^M
at
org.apache.derby.impl.sql.compile.ProjectRestrictNode.generate(ProjectRes
trictNode.java:1302)^M
at
org.apache.derby.impl.sql.compile.ProjectRestrictNode.generateMinion(Proj
ectRestrictNode.java:1440)^M
at
org.apache.derby.impl.sql.compile.ProjectRestrictNode.generate(ProjectRes
trictNode.java:1302)^M
at
org.apache.derby.impl.sql.compile.NormalizeResultSetNode.generate(Normali
zeResultSetNode.java:122)^M
at
org.apache.derby.impl.sql.compile.UpdateNode.generate(UpdateNode.java:808
)^M
at
org.apache.derby.impl.sql.compile.StatementNode.generate(StatementNode.ja
va:347)^M
at
org.apache.derby.impl.sql.GenericStatement.prepMinion(GenericStatement.ja
va:447)^M
at
org.apache.derby.impl.sql.GenericStatement.prepare(GenericStatement.java:
88)^M
at
org.apache.derby.impl.sql.conn.GenericLanguageConnectionContext.prepareIn
ternalStatement(GenericLanguageConnectionContext.java:742)^M
at
org.apache.derby.impl.jdbc.EmbedStatement.execute(EmbedStatement.java:567
)^M
at
org.apache.derby.impl.jdbc.EmbedStatement.execute(EmbedStatement.java:516
)^M
at
org.apache.derbyTesting.functionTests.tests.lang.CollationTest2.runAlterT
ableAddColumn(CollationTest2.java:625)^M
at
org.apache.derbyTesting.functionTests.tests.lang.CollationTest2.runTestIt
er(CollationTest2.java:702)^M
at
org.apache.derbyTesting.functionTests.tests.lang.CollationTest2.testEngli
shCollation(CollationTest2.java:722)^M
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)^M
at
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java
:64)^M
at
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorI
mpl.java:43)^M
at java.lang.reflect.Method.invoke(Method.java:615)^M
at junit.framework.TestCase.runTest(TestCase.java:154)^M
at junit.framework.TestCase.runBare(TestCase.java:127)^M
>
> Looking at stack trace, it looks like something is wrong in maybe my
> code generation changes and wondered if someone familiar with code
> generation can tell me what I am doing wrong. I will keep debugging but
> any help will be greatly appreciated.
>
> thanks,
> Mamta
>
>
>
Re: DERBY-1478 subtask DERBY-2583 - need help in debugging stack trace thrown during code generation
Posted by Mamta Satoor <ms...@gmail.com>.
I forgot to mention that another reason for including a pushDataValueFactory
in BaseTypeCompiler is ExpressionClassBuilder class is protected and hence
it is not visible outside of impl.sql.compile package and base of
CharTypeCompiler, CLOBTypeCompiler which is TypeCompiler is defined in
iapi.sql.compile package and hence it can't see ExpressionClassBuilder with
it's current protected definition. TypeCompiler needs access to
ExpressionClassBuilder if we want to pass ExpressionClassBuilder as
parameter to generateDataValue and generateNull so that they can utilize
pushDataValueFactory defined on ExpressionClassBuilder. I remember changing
the definition of ExpressionClassBuilder to public. I can spend more time on
more/exact details to explain why I defined pushDataValueFactory in
BaseTypeCompiler.
Mamta
On 5/14/07, Mamta Satoor <ms...@gmail.com> wrote:
>
> Dan, you are ofcourse right about problem being BaseTypeCompiler holding
> onto a reference to a declared method beyond one generated class. Once I
> removed caching of that reference, I don't get the stack trace for my simple
> test case anymore. Thank you.
>
> As for why I added the pushDataValueFactory() to BaseTypeCompiler, let me
> try to dig my memory. ExpressionClassBuilder is not passed to generateNull
> and generateDataValue. In my local codeline, I had made changes so that
> ExpressionClassBuilder gets passed to these 2 methods. (This had required
> quite a few changes for different callers to now pass
> ExpressionClassBuilder). But the main problem had something to do with
> getBaseClassName() in ExpressionClassBuilder.pushDataValueFactory at line
> 639 not returning the correct value. I wish I could recall exactly why
> I decided to create a new method rather than use what is in
> ExpressionClassBuilder. I can try to backtrace my steps to find out the
> exact reason if you would like.
>
> Mamta
>
>
> On 5/14/07, Daniel John Debrunner <djd@apache.org > wrote:
> >
> > Mamta Satoor wrote:
> > > Hi,
> > >
> > > I checked in code on April 24th revision 532082 for DERBY-2583 "At
> > code
> > > generation time, look at collation type to determine what kind of DVD
> > > should get generated for character types."
> > >
> > > The intention of the commit was to generate following
> > > StringDataValueObject.getValue (DataValueFactory.getCharacterCollator
> > (collationType));
> > >
> > >
> > > This code generation change went in
> > > BaseTypeCompiler.generateCollationSensitiveDataValue and it looked as
> > > follows
> > > protected void generateCollationSensitiveDataValue(MethodBuilder mb,
> > > int collationType, String className){
> > > if (collationType == StringDataValue.COLLATION_TYPE_UCS_BASIC)
> > > return;
> > > //In case of character DVDs, for territory based collation, we need
> > to
> > > //generate DVDs with territory based RuleBasedCollator and hence we
> > > //need to generate CollatorSQLChar/CollatorSQLVarchar/
> > > //CollatorSQLLongvarchar/CollatorSQLClob
> > > pushDataValueFactory(mb, className);
> >
> >
> > > Looking at stack trace, it looks like something is wrong in maybe my
> > > code generation changes and wondered if someone familiar with code
> > > generation can tell me what I am doing wrong. I will keep debugging
> > but
> > > any help will be greatly appreciated.
> >
> > The issue may be to do with the method you added to BaseTypeCompiler
> >
> > private void pushDataValueFactory(MethodBuilder mb, String className)
> >
> > ExpressionClassBuilder already has a pushDataValueFactory(), was there a
> >
> > need to create another one?
> >
> > The problem may be that ExpressionClassBuilder's lifetime is a single
> > class generation, thus it's fine for its pushDataValueFactory to hold a
> > reference to a declared method from MethodBuilder.describeMethod(). But
> > the lifetime of the BaseTypeCompiler objects may be longer, thus it may
> > be trying to use a reference to one method in one generated class in
> > another generated class.
> >
> > Dan.
> >
> >
>
Re: DERBY-1478 subtask DERBY-2583 - need help in debugging stack trace thrown during code generation
Posted by Mamta Satoor <ms...@gmail.com>.
Dan, you are ofcourse right about problem being BaseTypeCompiler holding
onto a reference to a declared method beyond one generated class. Once I
removed caching of that reference, I don't get the stack trace for my simple
test case anymore. Thank you.
As for why I added the pushDataValueFactory() to BaseTypeCompiler, let me
try to dig my memory. ExpressionClassBuilder is not passed to generateNull
and generateDataValue. In my local codeline, I had made changes so that
ExpressionClassBuilder gets passed to these 2 methods. (This had required
quite a few changes for different callers to now pass
ExpressionClassBuilder). But the main problem had something to do with
getBaseClassName() in ExpressionClassBuilder.pushDataValueFactory at line
639 not returning the correct value. I wish I could recall exactly why
I decided to create a new method rather than use what is in
ExpressionClassBuilder. I can try to backtrace my steps to find out the
exact reason if you would like.
Mamta
On 5/14/07, Daniel John Debrunner <djd@apache.org > wrote:
>
> Mamta Satoor wrote:
> > Hi,
> >
> > I checked in code on April 24th revision 532082 for DERBY-2583 "At code
> > generation time, look at collation type to determine what kind of DVD
> > should get generated for character types."
> >
> > The intention of the commit was to generate following
> > StringDataValueObject.getValue (DataValueFactory.getCharacterCollator
> (collationType));
> >
> >
> > This code generation change went in
> > BaseTypeCompiler.generateCollationSensitiveDataValue and it looked as
> > follows
> > protected void generateCollationSensitiveDataValue(MethodBuilder mb,
> > int collationType, String className){
> > if (collationType == StringDataValue.COLLATION_TYPE_UCS_BASIC)
> > return;
> > //In case of character DVDs, for territory based collation, we need to
>
> > //generate DVDs with territory based RuleBasedCollator and hence we
> > //need to generate CollatorSQLChar/CollatorSQLVarchar/
> > //CollatorSQLLongvarchar/CollatorSQLClob
> > pushDataValueFactory(mb, className);
>
>
> > Looking at stack trace, it looks like something is wrong in maybe my
> > code generation changes and wondered if someone familiar with code
> > generation can tell me what I am doing wrong. I will keep debugging but
> > any help will be greatly appreciated.
>
> The issue may be to do with the method you added to BaseTypeCompiler
>
> private void pushDataValueFactory(MethodBuilder mb, String className)
>
> ExpressionClassBuilder already has a pushDataValueFactory(), was there a
> need to create another one?
>
> The problem may be that ExpressionClassBuilder's lifetime is a single
> class generation, thus it's fine for its pushDataValueFactory to hold a
> reference to a declared method from MethodBuilder.describeMethod(). But
> the lifetime of the BaseTypeCompiler objects may be longer, thus it may
> be trying to use a reference to one method in one generated class in
> another generated class.
>
> Dan.
>
>
Re: DERBY-1478 subtask DERBY-2583 - need help in debugging stack
trace thrown during code generation
Posted by Mike Matrigali <mi...@sbcglobal.net>.
Daniel John Debrunner wrote:
> Mamta Satoor wrote:
>
>> Hi,
>>
>> I checked in code on April 24th revision 532082 for DERBY-2583 "At
>> code generation time, look at collation type to determine what kind of
>> DVD should get generated for character types."
>>
>> The intention of the commit was to generate following
>> StringDataValueObject.getValue(DataValueFactory.getCharacterCollator(collationType));
>>
>>
>> This code generation change went in
>> BaseTypeCompiler.generateCollationSensitiveDataValue and it looked as
>> follows
>> protected void generateCollationSensitiveDataValue(MethodBuilder mb,
>> int collationType, String className){ if (collationType ==
>> StringDataValue.COLLATION_TYPE_UCS_BASIC)
>> return;
>> //In case of character DVDs, for territory based collation, we need to
>> //generate DVDs with territory based RuleBasedCollator and hence we
>> //need to generate CollatorSQLChar/CollatorSQLVarchar/
>> //CollatorSQLLongvarchar/CollatorSQLClob
>> pushDataValueFactory(mb, className);
>
>
>
>> Looking at stack trace, it looks like something is wrong in maybe my
>> code generation changes and wondered if someone familiar with code
>> generation can tell me what I am doing wrong. I will keep debugging
>> but any help will be greatly appreciated.
>
>
> The issue may be to do with the method you added to BaseTypeCompiler
>
> private void pushDataValueFactory(MethodBuilder mb, String className)
>
> ExpressionClassBuilder already has a pushDataValueFactory(), was there a
> need to create another one?
Is the idea here that we should add an argument and pass in an
ExpressionClassBuilder into
things generateNull and generateDataValue, and then use the
ExpressionClassBuilder.pushDataValueFactory.
>
> The problem may be that ExpressionClassBuilder's lifetime is a single
> class generation, thus it's fine for its pushDataValueFactory to hold a
> reference to a declared method from MethodBuilder.describeMethod(). But
> the lifetime of the BaseTypeCompiler objects may be longer, thus it may
> be trying to use a reference to one method in one generated class in
> another generated class.
>
> Dan.
>
>
>
Re: DERBY-1478 subtask DERBY-2583 - need help in debugging stack
trace thrown during code generation
Posted by Daniel John Debrunner <dj...@apache.org>.
Mamta Satoor wrote:
> Hi,
>
> I checked in code on April 24th revision 532082 for DERBY-2583 "At code
> generation time, look at collation type to determine what kind of DVD
> should get generated for character types."
>
> The intention of the commit was to generate following
> StringDataValueObject.getValue(DataValueFactory.getCharacterCollator(collationType));
>
>
> This code generation change went in
> BaseTypeCompiler.generateCollationSensitiveDataValue and it looked as
> follows
> protected void generateCollationSensitiveDataValue(MethodBuilder mb,
> int collationType, String className){
> if (collationType == StringDataValue.COLLATION_TYPE_UCS_BASIC)
> return;
> //In case of character DVDs, for territory based collation, we need to
> //generate DVDs with territory based RuleBasedCollator and hence we
> //need to generate CollatorSQLChar/CollatorSQLVarchar/
> //CollatorSQLLongvarchar/CollatorSQLClob
> pushDataValueFactory(mb, className);
> Looking at stack trace, it looks like something is wrong in maybe my
> code generation changes and wondered if someone familiar with code
> generation can tell me what I am doing wrong. I will keep debugging but
> any help will be greatly appreciated.
The issue may be to do with the method you added to BaseTypeCompiler
private void pushDataValueFactory(MethodBuilder mb, String className)
ExpressionClassBuilder already has a pushDataValueFactory(), was there a
need to create another one?
The problem may be that ExpressionClassBuilder's lifetime is a single
class generation, thus it's fine for its pushDataValueFactory to hold a
reference to a declared method from MethodBuilder.describeMethod(). But
the lifetime of the BaseTypeCompiler objects may be longer, thus it may
be trying to use a reference to one method in one generated class in
another generated class.
Dan.