Strange VM error in deployed exe when naming my method 'with'

Hi...


I today encountered a strange error occuring only in my delopyed
executable (Dolphin 6.02 actual download). The stack trace occurs each
time my method 'JRTSQLParser>>with' is called and always reads as follows:
-------------------------
18:41:40, Freitag, 1. August 2008: ERROR JRDBAView Error querying view
source code!
an Error('Unknown interrupt with 76777728')

ProcessorScheduler(Object)>>error:
ProcessorScheduler>>unusedInterrupt:
[] in ProcessorScheduler>>vmi:list:no:with:
BlockClosure>>ifCurtailed:
ProcessorScheduler>>vmi:list:no:with:
JRTSQLASTViewParser(JRTSQLParser)>>with
JRTSQLASTViewParser(JRTSQLViewParser)>>withViewAtt ributesClause
JRTSQLASTViewParser(JRTSQLViewParser)>>createViewS tatement
JRTSQLASTViewParser(JRTSQLViewParser)>>subParser
JRTSQLASTViewParser(JRWrapperParser)>>matchAll:
JRTSQLASTViewParser(JRAbstractParser)>>matchAndAss embleAll:
JRTSQLASTViewParser(JRAbstractParser)>>completeMat ch:
JRTSQLASTViewParser(JRAbstractParser)>>completeMat chTokens:
JRDBATSQLViewSourceCodeAnalyzer(JRASTSSourceCodeAn alyzer)>>analyze
JRDBATSQLViewSourceCodeAnalyzer(JRDBASourceCodeAna lyzer)>>analyze
[] in JRDBASQLServerDBAccess>>sourceCodeAnalyzerForView:
IdentityDictionary(LookupTable)>>at:ifAbsentPut:
JRDBASQLServerDBAccess>>sourceCodeAnalyzerForItem: ifAbsentPut:
JRDBASQLServerDBAccess>>sourceCodeAnalyzerForView:
JRDBASQLServerDBAccess>>queryViewSourceCode:
-------------------------

I could not make anything of this, the last called of my methods named
'with' consists of just one line calling another Smalltalk method. In
my desparation I finally renamed my method to something else, e.g.
'withh'. To my amazement, the deployed app now works. My method is the
only one in the image named 'with'. Didn't touch this code for a long
time and when I formerly deployed with an older 6.0x image / VM version
all was fine.

Is this possibly a bug in the ToGo-Executable's VM?

Puzzled...

Ciao

....Jochen

Hi...

after some investigation I think I found the cause - it is a combo of
encryption and the new byte code packing. Unfortunately this is not a
nice finding.

In the new VM there is the possibility of packed byte code into one
dword for method bytecode of size <=4. The method JRTSQLParser>>with has
a byte code of length 4 and encrypts to a same-sized byte array the last
element beeing 0 (zero). Unfortunately the bytecode packing assumes zero
to be no data and cuts off the trailing zero when storing the crypted
bytes. In the deployed exe the bytes are thus unpacked to 3 bytes
missing the last bytecode.

At the moment I cannot see how I could distinguish this case easily as
the en-/decryption is symmetriclal.

Ciao

....Jochen