[Pharo-dev] Reproducible VM Crash using UFFI

Guillermo Polito guillermopolito at gmail.com
Sun Oct 8 12:28:05 EDT 2017

Yeh, the most important thing is what Jan says there. What you want to
ensure is that you don't corrupt your memory (and particularly the heap).
If you do so (i.e., corruption) the only way you can come back is that you
remember the old uncorrupted value and, given that everything is still
working, you put it back where it belongs.

In any case, Hernan, I think this discussion belongs to the vm-dev list.

On Sun, Oct 8, 2017 at 1:32 PM, Jan Vrany <jan.vrany at fit.cvut.cz> wrote:

> > So I think we are talking about different things here. I don't want
> > to
> > save "bad memory block" errors nor dream about bullet proof VM, but
> > if
> > we know the bullet then let's use a nice bulletproof vest :)
> >
> This can be done and has been done.
> Following code would clearly result in segmentation violation:
> bytes := ExternalBytes address: 16r10 size: 100.
> bytes byteAt: 1 put: 10.
> There are smalltalk implementations out there that handle
> this and open a (smalltalk) debugger (see the screenshot).
> Of course, you can just abort, fix your code and
> try again.
> Of course, if you happen to overwrite your object memory
> or VM internal structures, you're screwed.
> As you said, you can still be shot and die, but the west can
> save your life in some cases :-)
> Best, Jan


Guille Polito

Research Engineer

Centre de Recherche en Informatique, Signal et Automatique de Lille

CRIStAL - UMR 9189

French National Center for Scientific Research - *http://www.cnrs.fr

*Web:* *http://guillep.github.io* <http://guillep.github.io>

*Phone: *+33 06 52 70 66 13
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.pharo.org/pipermail/pharo-dev_lists.pharo.org/attachments/20171008/ba110646/attachment-0002.html>

More information about the Pharo-dev mailing list