Posted by
Blair McGlashan-3 on
Feb 17, 2005; 3:38pm
URL: https://forum.world.st/Aaaaaaarrrggg-Broken-Image-tp3373131p3373137.html
"Fernando" <
[hidden email]> wrote in message
news:
[hidden email]...
> Hi,
>
> Yesterday I made a few 'experiments' that caused infinite recursions.
> This morning my image decided it had enough and refuses to work. It
> loads fine, but whenever I try to accept a mehtod it has a seizure:
>
> -------------------------------------------------------------------
> Index 33373 is out of bounds
>
> Process(Object)>>errorSubscriptBounds:
> Process(Object)>>errorAt:
> Process>>at:
> StackFrame>>method
> [] in Debugger>>markMethodAsUnbound:
>...
This is almost certainly recoverable. Here are a few things to try (and in
this order):
1) Try a "panic" (the scream button on the system folder toolbar)
2) Debugger allInstances do: [:each | each view destroy]
3) Debugger allInstances do: [:each | Smalltalk developmentSystem
removeEventsTriggeredFor: each]
4) Open the Process Monitor, if any processes are listed as being in state
'debug', terminate them using the command on the context menu.
>
> Anybody knows what might be wrong and how I can fix it? Is thsi sort
> of image-fit a common danger and if yes, how can you make sure your
> code survives it?
Its not that common, depending on what you are doing. In Smalltalk you are
not protected from damaging the system, so it is possible to mess up the
image. As you gain more experience, you will be less likely to damage the
image by mistake. Even if you do damage your image, the change log records
most of what you have done so you will be able to restore it at the cost of
some time. Ian Bartholomew's Chunk Browser tool is excellent for this
purpose. To avoid having to fire up the Chunk Browser, you should:
1) Ensure that all your work is packaged. Regularly save your packages. I
can't stress enough how important this is.
2) Regularly backup your image. I have a little batch file to do this that
copies the .img, .chg, and .sml files into a directory. I believe there are
also goodies available that do this automatically. You should be careful,
however, to maintain a reasonable history of backups to avoid overwriting a
good backup with a damaged image.
3) It is a good discipline to regularly "rebuild" your image. This involves
making a backup of your current working image. then start from a freshly
installed and patched image, and load your packages. This is essential to
ensure that your packages contain all your work, and pass your tests on
reload.
Lastly it is worth remembering that almost all apparently damaged images are
recoverable. Sometimes it requires a good deal of knowledge to achieve, and
it frequently makes more sense to start with ones latest backup and reapply
changes from the change log using the chunk browser. The decision as to
whether to recover, or rebuild from a backup, depends on the relative effort
involved. Each case will be different. If you do want to attempt recovery
then it is useful to know that if you put a file called 'postfix.st' into
the image directory, that the system will attempt to file this in (as a
chunked Smalltalk script) at a very early stage in the startup. This can be
useful for repairing damage that prevents the image from even starting up. A
very useful expression to insert in it in that circumstance is:
View allSubinstances do: [:each | each destroy]
This performs a "stronger" version of the panic command, and indeed is
sometimes useful in a running image when that command fails to get rid of a
lurking hidden view.
Regards
Blair