Posted by Blair McGlashan on May 18, 2004; 9:23pm
URL: https://forum.world.st/Crash-and-burn-object-table-limits-tp3370595p3370606.html

"Chris Uppal" <[hidden email]> wrote in message
news:[hidden email]...
> Hi,
>
> This one's probably for Blair.
>
> First, and just FYI, I have now for the first time exceeded the default
limits
> of the OT in "normal" activity.  I.e. not benchmarking or purposely
exploring
> the system limits.
>
> At least I assume that's why Dolphin just crashed with a dump (I can send
it to
> you if you want), as I was creating several million objects at the time.
>
> Secondly, and more disturbingly, I followed the instructions on the Wiki
for
> increasing the OT size but it didn't work.  Before doing so I used a
related
> expression to print out the value of the SDWord at the relevant location
(0x20)
> and it seemed OK, 0x800000 (or however many zeros).  Then saved the image,
then
> reran the expression (being careful to ensure that the #position: was
executed
> again!), and then exited without saving.  I assume that's how to get the
image
> patched without overwriting the OT-size datum.
>
> But the saved image won't re-load.   In fact Dolphin crashes trying to
open it
> :-(

Well not knowing what you attempted to set it to, I would guess that if
failed because of the sequence of operations you used. A clue is that the
expression on the Wiki uses a FileStream, which is a buffered stream.
Ringing any bells yet? If not read on - lets say you did this:
1) fs := FileStream readWrite: 'dolphin.img'. fs beBinary. (or the
eexpression from the Wiki)
2) fs position: 16r20.
3) fs nextSDWORD.
4) Save the image.
5) fs postion: 16r20.
6) fs nextSDWORDPut: <some larger, but reasonable, value>
7) fs close (or flush)

Then what would have happened is that on the first read the FileStream would
have the first 8Kb of the file. The File would then have been overwritten
with the newly saved image (note that important details on that first page
will change each time the image is saved). Now you update the buffer writing
the new header value. Finally you close the filestream and the modified page
gets written back to the file. I'm quite surprised its possible to do this
without getting some sort of sharing violation (must be something to do with
the default modes used), but anyway the net result would be an invalid image
file because the 8Kb of the original image file in the buffer would not be
valid for the newly saved image, hence it gets corrupted.

It is also possible to choose a value that is invalid (too large or too
small), so I would suggest modifying the original value (approx 8 million)
by two as a start point. If you make it too large, then it is possible to
run out of virtual memory space when allocating the object table at startup,
or when an image is saved.

Regards

Blair