[squeak-dev] Save as new image -> ModificationForbidden!

Thiede, Christoph Christoph.Thiede at student.hpi.uni-potsdam.de
Wed Mar 25 08:31:49 UTC 2020


Hi Marcel, hi Levente!


> For starters, the #printString of modifiable arrays is wrong if literal arrays should be immutable:

>
> x := {1. 2. 3}.
> x at: 1 put: #foo.
> x "#(#foo 2 3) --- wrong print string!"

Why do you think this is the wrong print string? {#foo. 2. 3} is also printed as #(#foo 2 3).

Also, the following example shows that brace nodes generate a new instance each time:

c := Object newSubclass.
c compile: 'foo ^ {1. 2. 3}'.
o := c new.
o foo at: 1 put: #foo.
o foo. "#(1 2 3)"

Best,
Christoph

________________________________
Von: Squeak-dev <squeak-dev-bounces at lists.squeakfoundation.org> im Auftrag von Taeumel, Marcel
Gesendet: Mittwoch, 25. März 2020 09:19:01
An: gettimothy via Squeak-dev
Betreff: Re: [squeak-dev] Save as new image -> ModificationForbidden!

Hi Levente, hi Christoph.

> I cannot reproduce this using a fresh Trunk image

I am not exactly sure why my Trunk image keeps generating those private keys. But I am happy that the bug surfaced. Now we need to address it. :-)

> The main issue is that literal objects created by Compiler >> #evaluate:*  are now immutable but I think they shouldn't be. What do you think?

Well, I think that literals producing numbers, strings, or symbols should be protected in this way. For literal arrays, I am not so sure.

For starters, the #printString of modifiable arrays is wrong if literal arrays should be immutable:

x := {1. 2. 3}.
x at: 1 put: #foo.
x "#(#foo 2 3) --- wrong print string!"

y := #(1 2 3).
y at: 1 put: #foo. "ModificationForbidden"

Then, in the past, I have been complaining about the array cache in compiled methods:

someDefault
   ^ #(1 2 3)

In this case, I expected the method to always return a new array. Now, it is immutable, but that is not as expected. I think. Is it still cached?

***

In my case here, the code tries to change a LargePositiveInteger, not an array, which has always been wrong. :-) Is there a way to safely discard a LargePositiveInteger from memory?

> System-ul.1148 should work the issue around. Please let me know if it
helped.

Not quite. I think have to manually clear the current keys in the SecurityManager first.

Best,
Marcel

Am 24.03.2020 21:18:51 schrieb Levente Uzonyi <leves at caesar.elte.hu>:

Hi Marcel,

System-ul.1148 should work the issue around. Please let me know if it
helped.
The main issue is that literal objects created by Compiler >> #evaluate:*
are now immutable but I think they shouldn't be. What do you think?


Levente

On Tue, 24 Mar 2020, Marcel Taeumel wrote:

> Hi, there.
>
> I just wanted to save a 32-bit image (Update 19541, VM 202003021730, Windows 10) under a new filename.
>
> Boom! ModificationForbidden!
>
> Here is the interesting stack:
>
> Context>>modificationForbiddenFor:at:put:
> LargePositiveInteger(Object)>>basicAt:put:
> SecurityManager>>flushSecurityKey:
> SecurityManager>>flushSecurityKeys
> SecurityManager>>shutDown
> SecurityManager class>>shutDown
> SecurityManager class(Behavior)>>shutDown:
> [] in SmalltalkImage>>send:toClassesNamedIn:with:
> OrderedCollection>>do:
> SmalltalkImage>>send:toClassesNamedIn:with:
> SmalltalkImage>>processShutDownList:
>
> Well, that code tries to change a LargePositiveInteger:
>
> SecurityManager >> flushSecurityKey: aKey
> "Flush a security key"
> | n |
> n := aKey first.
> 1 to: n basicSize do:[:i| n basicAt: i put: 0].
> n := aKey second.
> 1 to: n basicSize do:[:i| n basicAt: i put: 0].
>
> How to fix that without breaking security measures or the underlying concept?
>
> Best,
> Marcel
>
>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.squeakfoundation.org/pipermail/squeak-dev/attachments/20200325/372df599/attachment.html>


More information about the Squeak-dev mailing list