3 ms·
Running the analogous ln -sf /dev/zero /lib/x86_64-linux-gnu/libc.so.6 will have an analogous effect on an "alive" Unix image. I mean, a Unix machine. :-)
by tonyg 6y ago
Running the analogous
ln -sf /dev/zero /lib/x86_64-linux-gnu/libc.so.6
will have an analogous effect on an "alive" Unix image. I mean, a Unix machine. :-)
Incidentally, in the latest Squeak,
True := False.
doesn't work -- the compiler complains that you can't assign into a read-only variable. So let's try this:
Smalltalk at: #True put: False.
But now the metaprogramming system complains you're trying to modify a read-only binding! So we view source on ClassBinding>>value:, and see that a resumable exception is being used to guard the modification, so let's explicitly signal that we REALLY want to modify that binding:
[Smalltalk at: #True put: False]
on: AttemptToWriteReadOnlyGlobal
do: [:ex | ex resume: true].
Finally! Now, evaluating "True" yields "False".
But the image keeps running! Use of the literal class True seems to be rare enough that things are OK for at least several minutes after the change.
Doing this, however, definitely should immediately torpedo things:
true become: false.
... huh. It didn't work. It used to! Again, on this current Squeak version, we see a different behaviour. This time, it says "Cannot execute #elementsExchangeIdentityWith: on read-only object #(false)".
So we'll have to try harder:
true becomeForward: false.
That doesn't work either! Same error as for #become:.
Welp, I'm actually all out of ways to crash this modern image in analogous ways to the easy pitfalls of images of yesteryear...