Primitive Object>>isImmutable: failed (0)

Hi...

facing a problem I have no still no idea about the cause after two days
of elaborating i now decided ask for help.

After a long time of development using a single image I now tried to
load the relevant packages into a fresh image and deploy my app just to
check that this is working when I need it. I loaded the packages both
via StS Project and manually fromFile system.

Inside the new image (freshly generated Professional.img), everything
works great, but when I deploy my application using the new image, and
then try to start the resulting app, it fails with the error message
shown in the topic line. Deploying from the original image (located in
the same folder as the new one) works just fine! They use the same ToGo
executable.

(Yes, I added the missing three methods to ProtectedProductSerialNumber
:-)).

I never saw such a message before (interesting portion of stack trace
appended). I at first suspected my encoding / decoding methods (I have
my own pure ST versions of SecureHashAlgorithm and PC1Cipher to be
independent of the Crypto dll). Indeed, when disabling encryption
altogether by returning an empty array from
MySessionManager>>encryptedPackageNames the deployed app works also from
the new image (in this case no isImmutable: calls are issued). returning
just one single small encrypted package spoils it again, though.

I then logged out my encryption / decryption and it seems to work just
fine, but after decoding the third method bytecode it suddenly fails
with the above meassage when attempting to set the (correctly decoded)
byteCodes.

I also used the original dll-dependent classes but there it failed the
same way.

The code where it fails is in CompiledMethod(CompiledCode)>>byteCodes:,
near the bottom of the method there is the offending setImmutable: call.

One failing byte code array to be set is #[171 17 177 105] (the
encrypted one was #[248 176 156 217]).

I really have no clues what to do next (this is a primitive failing an a
SmallInteger) and would highly appreciate any help!

Ciao

....Jochen


<snip>
{092703A4: cf 09270385, sp 092703B8, bp 092703A0, ip 2,
SmallInteger(Object)>>isImmutable:}
receiver: 886606037
arg[0]: true

{09270384: cf 09270361, sp 09270398, bp 09270380, ip 75,
CompiledMethod(CompiledCode)>>byteCodes:}
receiver: JRDBASourceCodeRef>>addDescriptor:
arg[0]: a ByteArray
env temp[0]: 886606037
env temp[1]: nil

{09270360: cf 09270331, sp 09270378, bp 0927034C, ip 81,
JRPC1ProductProtector>>cipherMethod:}
receiver: a JRPC1ProductProtector
arg[0]: JRDBASourceCodeRef>>addDescriptor:
stack temp[0]: a JRPC1Cipher
stack temp[1]: a ByteArray
stack temp[2]: a ByteArray
stack temp[3]: a FileStream
</snip>

Hi...

an update: it seems that my old image is different to the new one
regarding CompiledCode>>byteCodes:. The old method is a simple setter
while the new (crashing) one does a lot about packing and sets
immutable. The image major version is the same for both images,
though?!? Could anybody tell when this change was incorporated?

I could fix the crashing on startup with this code in the new image:
codss class == SmallInteger ifFalse: [codes isImmutable:true].
self assert: [codes isImmutable].
The added assert is also always true as SmalInteger instances are always
immutable.

Of course, albeit the App works fine now deployed from the new image
including encryption this makes me a bit uneasy as noone else seems to
have experienced this yet. Any ideas?

Ciao

....Jochen


Jochen Riekhof schrieb:
> Hi...
>
> facing a problem I have no still no idea about the cause after two days
> of elaborating i now decided ask for help.
>
> After a long time of development using a single image I now tried to
> load the relevant packages into a fresh image and deploy my app just to
> check that this is working when I need it. I loaded the packages both
> via StS Project and manually fromFile system.
>
> Inside the new image (freshly generated Professional.img), everything
> works great, but when I deploy my application using the new image, and
> then try to start the resulting app, it fails with the error message
> shown in the topic line. Deploying from the original image (located in
> the same folder as the new one) works just fine! They use the same ToGo
> executable.
>
> (Yes, I added the missing three methods to ProtectedProductSerialNumber
> :-)).
>
> I never saw such a message before (interesting portion of stack trace
> appended). I at first suspected my encoding / decoding methods (I have
> my own pure ST versions of SecureHashAlgorithm and PC1Cipher to be
> independent of the Crypto dll). Indeed, when disabling encryption
> altogether by returning an empty array from
> MySessionManager>>encryptedPackageNames the deployed app works also from
> the new image (in this case no isImmutable: calls are issued). returning
> just one single small encrypted package spoils it again, though.
>
> I then logged out my encryption / decryption and it seems to work just
> fine, but after decoding the third method bytecode it suddenly fails
> with the above meassage when attempting to set the (correctly decoded)
> byteCodes.
>
> I also used the original dll-dependent classes but there it failed the
> same way.
>
> The code where it fails is in CompiledMethod(CompiledCode)>>byteCodes:,
> near the bottom of the method there is the offending setImmutable: call.
>
> One failing byte code array to be set is #[171 17 177 105] (the
> encrypted one was #[248 176 156 217]).
>
> I really have no clues what to do next (this is a primitive failing an a
> SmallInteger) and would highly appreciate any help!
>
> Ciao
>
> ...Jochen
>
>
> <snip>
> {092703A4: cf 09270385, sp 092703B8, bp 092703A0, ip 2,
> SmallInteger(Object)>>isImmutable:}
> receiver: 886606037
> arg[0]: true
>
> {09270384: cf 09270361, sp 09270398, bp 09270380, ip 75,
> CompiledMethod(CompiledCode)>>byteCodes:}
> receiver: JRDBASourceCodeRef>>addDescriptor:
> arg[0]: a ByteArray
> env temp[0]: 886606037
> env temp[1]: nil
>
> {09270360: cf 09270331, sp 09270378, bp 0927034C, ip 81,
> JRPC1ProductProtector>>cipherMethod:}
> receiver: a JRPC1ProductProtector
> arg[0]: JRDBASourceCodeRef>>addDescriptor:
> stack temp[0]: a JRPC1Cipher
> stack temp[1]: a ByteArray
> stack temp[2]: a ByteArray
> stack temp[3]: a FileStream
> </snip>

Hi Jochen,

Sorry I have nothing to offer - except the image I am using has the newer
version of byteCodes: (its a 6.02) image. I am not doing any encryption stuff
so I don't know if we are comparing like with like.

Its worth getting into the habbit of always deploying from a clean image
(I have a little tool that does this for me) as you can sometimes catch these
little gotcha's earlier if you deploy frequently.

Tim


> Hi...
>
> an update: it seems that my old image is different to the new one
> regarding CompiledCode>>byteCodes:. The old method is a simple setter
> while the new (crashing) one does a lot about packing and sets
> immutable. The image major version is the same for both images,
> though?!? Could anybody tell when this change was incorporated?
>
> I could fix the crashing on startup with this code in the new image:
> codss class == SmallInteger ifFalse: [codes isImmutable:true].
> self assert: [codes isImmutable].
> The added assert is also always true as SmalInteger instances are
> always
> immutable.
> Of course, albeit the App works fine now deployed from the new image
> including encryption this makes me a bit uneasy as noone else seems to
> have experienced this yet. Any ideas?
>
> Ciao
>
> ...Jochen
>
> Jochen Riekhof schrieb:
>
>> Hi...
>>
>> facing a problem I have no still no idea about the cause after two
>> days of elaborating i now decided ask for help.
>>
>> After a long time of development using a single image I now tried to
>> load the relevant packages into a fresh image and deploy my app just
>> to check that this is working when I need it. I loaded the packages
>> both via StS Project and manually fromFile system.
>>
>> Inside the new image (freshly generated Professional.img), everything
>> works great, but when I deploy my application using the new image,
>> and then try to start the resulting app, it fails with the error
>> message shown in the topic line. Deploying from the original image
>> (located in the same folder as the new one) works just fine! They use
>> the same ToGo executable.
>>
>> (Yes, I added the missing three methods to
>> ProtectedProductSerialNumber :-)).
>>
>> I never saw such a message before (interesting portion of stack trace
>> appended). I at first suspected my encoding / decoding methods (I
>> have my own pure ST versions of SecureHashAlgorithm and PC1Cipher to
>> be independent of the Crypto dll). Indeed, when disabling encryption
>> altogether by returning an empty array from
>> MySessionManager>>encryptedPackageNames the deployed app works also
>> from the new image (in this case no isImmutable: calls are issued).
>> returning just one single small encrypted package spoils it again,
>> though.
>>
>> I then logged out my encryption / decryption and it seems to work
>> just fine, but after decoding the third method bytecode it suddenly
>> fails with the above meassage when attempting to set the (correctly
>> decoded) byteCodes.
>>
>> I also used the original dll-dependent classes but there it failed
>> the same way.
>>
>> The code where it fails is in
>> CompiledMethod(CompiledCode)>>byteCodes:, near the bottom of the
>> method there is the offending setImmutable: call.
>>
>> One failing byte code array to be set is #[171 17 177 105] (the
>> encrypted one was #[248 176 156 217]).
>>
>> I really have no clues what to do next (this is a primitive failing
>> an a SmallInteger) and would highly appreciate any help!
>>
>> Ciao
>>
>> ...Jochen
>>
>> <snip>
>> {092703A4: cf 09270385, sp 092703B8, bp 092703A0, ip 2,
>> SmallInteger(Object)>>isImmutable:}
>> receiver: 886606037
>> arg[0]: true
>> {09270384: cf 09270361, sp 09270398, bp 09270380, ip 75,
>> CompiledMethod(CompiledCode)>>byteCodes:}
>> receiver: JRDBASourceCodeRef>>addDescriptor:
>> arg[0]: a ByteArray
>> env temp[0]: 886606037
>> env temp[1]: nil
>> {09270360: cf 09270331, sp 09270378, bp 0927034C, ip 81,
>> JRPC1ProductProtector>>cipherMethod:}
>> receiver: a JRPC1ProductProtector
>> arg[0]: JRDBASourceCodeRef>>addDescriptor:
>> stack temp[0]: a JRPC1Cipher
>> stack temp[1]: a ByteArray
>> stack temp[2]: a ByteArray
>> stack temp[3]: a FileStream
>> </snip>

Hi Jochen,

this is a guess but does isImmtable: fail if sent to SmallIntegers,
and does deployment replace message selectors with SallIntegers to save
space? if so, I suspect that what is happening is that isImmutable: is
being sent to a selector which in your development image is a Symbol and
in your deployment image is a SmallInteger.

Just a guess...

Jochen Riekhof wrote:
> Hi...
>
> facing a problem I have no still no idea about the cause after two days
> of elaborating i now decided ask for help.
>
> After a long time of development using a single image I now tried to
> load the relevant packages into a fresh image and deploy my app just to
> check that this is working when I need it. I loaded the packages both
> via StS Project and manually fromFile system.
>
> Inside the new image (freshly generated Professional.img), everything
> works great, but when I deploy my application using the new image, and
> then try to start the resulting app, it fails with the error message
> shown in the topic line. Deploying from the original image (located in
> the same folder as the new one) works just fine! They use the same ToGo
> executable.
>
> (Yes, I added the missing three methods to ProtectedProductSerialNumber
> :-)).
>
> I never saw such a message before (interesting portion of stack trace
> appended). I at first suspected my encoding / decoding methods (I have
> my own pure ST versions of SecureHashAlgorithm and PC1Cipher to be
> independent of the Crypto dll). Indeed, when disabling encryption
> altogether by returning an empty array from
> MySessionManager>>encryptedPackageNames the deployed app works also from
> the new image (in this case no isImmutable: calls are issued). returning
> just one single small encrypted package spoils it again, though.
>
> I then logged out my encryption / decryption and it seems to work just
> fine, but after decoding the third method bytecode it suddenly fails
> with the above meassage when attempting to set the (correctly decoded)
> byteCodes.
>
> I also used the original dll-dependent classes but there it failed the
> same way.
>
> The code where it fails is in CompiledMethod(CompiledCode)>>byteCodes:,
> near the bottom of the method there is the offending setImmutable: call.
>
> One failing byte code array to be set is #[171 17 177 105] (the
> encrypted one was #[248 176 156 217]).
>
> I really have no clues what to do next (this is a primitive failing an a
> SmallInteger) and would highly appreciate any help!
>
> Ciao
>
> ...Jochen
>
>
> <snip>
> {092703A4: cf 09270385, sp 092703B8, bp 092703A0, ip 2,
> SmallInteger(Object)>>isImmutable:}
> receiver: 886606037
> arg[0]: true
>
> {09270384: cf 09270361, sp 09270398, bp 09270380, ip 75,
> CompiledMethod(CompiledCode)>>byteCodes:}
> receiver: JRDBASourceCodeRef>>addDescriptor:
> arg[0]: a ByteArray
> env temp[0]: 886606037
> env temp[1]: nil
>
> {09270360: cf 09270331, sp 09270378, bp 0927034C, ip 81,
> JRPC1ProductProtector>>cipherMethod:}
> receiver: a JRPC1ProductProtector
> arg[0]: JRDBASourceCodeRef>>addDescriptor:
> stack temp[0]: a JRPC1Cipher
> stack temp[1]: a ByteArray
> stack temp[2]: a ByteArray
> stack temp[3]: a FileStream
> </snip>


--
The surest sign that intelligent life exists elsewhere in Calvin &
the universe is that none of it has tried to contact us. Hobbes.
--
Eliot ,,,^..^,,, Smalltalk - scene not herd

On Tue, 22 Jul 2008 18:19:26 -0700, Eliot Miranda <eliotm@pacbell.net>
wrote:

> this is a guess but does isImmtable: fail if sent to SmallIntegers,
>and does deployment replace message selectors with SallIntegers to save
>space? if so, I suspect that what is happening is that isImmutable: is
>being sent to a selector which in your development image is a Symbol and
>in your deployment image is a SmallInteger.

According to the method comment the VM does allow sending
#isImmutable: to an already immutable object, like a SmallInteger, if
the argument is #true. Evaluating the code for Jochen's walkback in a
workspace ...

886606037 isImmutable: true

.... doesn't cause a problem in Dolphin 6.1b2. I'm not quite sure
which version of Dolphin Jochen is using though.


--
Ian

The from address is valid

Hi Tim...

> Its worth getting into the habbit of always deploying from a clean image
> (I have a little tool that does this for me) as you can sometimes catch
> these little gotcha's earlier if you deploy frequently.

Thank you for this! After this experience, it sounds like a splendid
idea :-).

Please see my other post to this thread for the resolution of this issue.

Ciao

....Jochen



Tim M schrieb:
> Hi Jochen,
>
> Sorry I have nothing to offer - except the image I am using has the
> newer version of byteCodes: (its a 6.02) image. I am not doing any
> encryption stuff so I don't know if we are comparing like with like.
>
> Its worth getting into the habbit of always deploying from a clean image
> (I have a little tool that does this for me) as you can sometimes catch
> these little gotcha's earlier if you deploy frequently.
>
> Tim
>
>
>> Hi...
>>
>> an update: it seems that my old image is different to the new one
>> regarding CompiledCode>>byteCodes:. The old method is a simple setter
>> while the new (crashing) one does a lot about packing and sets
>> immutable. The image major version is the same for both images,
>> though?!? Could anybody tell when this change was incorporated?
>>
>> I could fix the crashing on startup with this code in the new image:
>> codss class == SmallInteger ifFalse: [codes isImmutable:true].
>> self assert: [codes isImmutable].
>> The added assert is also always true as SmalInteger instances are
>> always
>> immutable.
>> Of course, albeit the App works fine now deployed from the new image
>> including encryption this makes me a bit uneasy as noone else seems to
>> have experienced this yet. Any ideas?
>>
>> Ciao
>>
>> ...Jochen
>>
>> Jochen Riekhof schrieb:
>>
>>> Hi...
>>>
>>> facing a problem I have no still no idea about the cause after two
>>> days of elaborating i now decided ask for help.
>>>
>>> After a long time of development using a single image I now tried to
>>> load the relevant packages into a fresh image and deploy my app just
>>> to check that this is working when I need it. I loaded the packages
>>> both via StS Project and manually fromFile system.
>>>
>>> Inside the new image (freshly generated Professional.img), everything
>>> works great, but when I deploy my application using the new image,
>>> and then try to start the resulting app, it fails with the error
>>> message shown in the topic line. Deploying from the original image
>>> (located in the same folder as the new one) works just fine! They use
>>> the same ToGo executable.
>>>
>>> (Yes, I added the missing three methods to
>>> ProtectedProductSerialNumber :-)).
>>>
>>> I never saw such a message before (interesting portion of stack trace
>>> appended). I at first suspected my encoding / decoding methods (I
>>> have my own pure ST versions of SecureHashAlgorithm and PC1Cipher to
>>> be independent of the Crypto dll). Indeed, when disabling encryption
>>> altogether by returning an empty array from
>>> MySessionManager>>encryptedPackageNames the deployed app works also
>>> from the new image (in this case no isImmutable: calls are issued).
>>> returning just one single small encrypted package spoils it again,
>>> though.
>>>
>>> I then logged out my encryption / decryption and it seems to work
>>> just fine, but after decoding the third method bytecode it suddenly
>>> fails with the above meassage when attempting to set the (correctly
>>> decoded) byteCodes.
>>>
>>> I also used the original dll-dependent classes but there it failed
>>> the same way.
>>>
>>> The code where it fails is in
>>> CompiledMethod(CompiledCode)>>byteCodes:, near the bottom of the
>>> method there is the offending setImmutable: call.
>>>
>>> One failing byte code array to be set is #[171 17 177 105] (the
>>> encrypted one was #[248 176 156 217]).
>>>
>>> I really have no clues what to do next (this is a primitive failing
>>> an a SmallInteger) and would highly appreciate any help!
>>>
>>> Ciao
>>>
>>> ...Jochen
>>>
>>> <snip>
>>> {092703A4: cf 09270385, sp 092703B8, bp 092703A0, ip 2,
>>> SmallInteger(Object)>>isImmutable:}
>>> receiver: 886606037
>>> arg[0]: true
>>> {09270384: cf 09270361, sp 09270398, bp 09270380, ip 75,
>>> CompiledMethod(CompiledCode)>>byteCodes:}
>>> receiver: JRDBASourceCodeRef>>addDescriptor:
>>> arg[0]: a ByteArray
>>> env temp[0]: 886606037
>>> env temp[1]: nil
>>> {09270360: cf 09270331, sp 09270378, bp 0927034C, ip 81,
>>> JRPC1ProductProtector>>cipherMethod:}
>>> receiver: a JRPC1ProductProtector
>>> arg[0]: JRDBASourceCodeRef>>addDescriptor:
>>> stack temp[0]: a JRPC1Cipher
>>> stack temp[1]: a ByteArray
>>> stack temp[2]: a ByteArray
>>> stack temp[3]: a FileStream
>>> </snip>
>
>

Hi...

first, let me thank everybody answering for their assistance! Finally
and with your aid I found the cause of my troubles:

Issue 1:
It seems that at the time of updating my installation to 6.02 I somehow
did not recreate my image(s) but assumed that updating them to PL2 using
Live update would update everything just in the same way as if I would
recreate my working images from a fresh 6.02 Professional.img. As it
seems this is not always the case :-).

Issue 2:
When installing 6.02 I did not replace my ToGo.exe stubs, thus running a
stale VM. As the CompiledCode>>setImmutable: method was also not updated
this caused no problems. The trouble came when i recreated my working
image using a real 6.02 Professional.img but failed to replace the exe
stubs as well as now the used stale VM inside the stub was not up to the
task of handling the setImmutable: calls to SmallIntegers.

It would have been a bad idea indeed to include the new version of the
method in PL2 as (I believe) just the image is updated by the Live
Update. If OA would have done otherwise and updated the
CompiledCode>>setImmutable: method exactly my issue would have occured
for all updating users.

Tbank you all again for support!

Ciao

....Jochen


IanB schrieb:
> On Tue, 22 Jul 2008 18:19:26 -0700, Eliot Miranda <eliotm@pacbell.net>
> wrote:
>
>> this is a guess but does isImmtable: fail if sent to SmallIntegers,
>> and does deployment replace message selectors with SallIntegers to save
>> space? if so, I suspect that what is happening is that isImmutable: is
>> being sent to a selector which in your development image is a Symbol and
>> in your deployment image is a SmallInteger.
>
> According to the method comment the VM does allow sending
> #isImmutable: to an already immutable object, like a SmallInteger, if
> the argument is #true. Evaluating the code for Jochen's walkback in a
> workspace ...
>
> 886606037 isImmutable: true
>
> ... doesn't cause a problem in Dolphin 6.1b2. I'm not quite sure
> which version of Dolphin Jochen is using though.
>
>

Hi Jochen,

> image using a real 6.02 Professional.img but failed to replace the exe
> stubs as well as now the used stale VM inside the stub was not up to
> the task of handling the setImmutable: calls to SmallIntegers.

Not sure if you know about Udo's ResourceChangingImageStripper - in many
cases you don't have to touch your stub becuase his stripper does everything
for you - binding in icons and resources automagically (thus when I shell
out to a new image and run an automated strip - that stripper does it all).

Tim

Hi Tim...

thank you for the info! I have got the package a while ago from Udo. At
that time I had just set up everything myself using reshacker as
Stub-Patcher so I never really use it. When I find the time to implement
your "fresh image deployment" I wil surely use it.

Ciao

....Jochen



Tim M schrieb:
> Hi Jochen,
>
>> image using a real 6.02 Professional.img but failed to replace the exe
>> stubs as well as now the used stale VM inside the stub was not up to
>> the task of handling the setImmutable: calls to SmallIntegers.
>
> Not sure if you know about Udo's ResourceChangingImageStripper - in many
> cases you don't have to touch your stub becuase his stripper does
> everything for you - binding in icons and resources automagically (thus
> when I shell out to a new image and run an automated strip - that
> stripper does it all).
> Tim
>
>