2015-06-16 7:41 GMT+02:00 [email protected] <[email protected]>:

> Gille fixed one of my locked up images with his Oz tooling.
>
> I'd welcome that thing to be more widely usable.
>
> No clue about the current state of affairs on that front.
>
> Phil
>
>
Did you try to open (a copy of) the changes file with a new/fresh image?
Or you can use :

ExternalChangesBrowser openOn:'FULLNAME_OF_OTHER_CHANGES_FILE'
to open a changes browser.

nicolai



>
> On Tue, Jun 16, 2015 at 2:00 AM, Peter Uhnák <[email protected]> wrote:
>
>> In moment of my utter brilliance I managed to save image without noticing
>> that I have infinite loop running...
>> So it obviously crashed and launching is quite problematic.
>> I managed to recompile infringing method from a startup script, since it
>> seems strangly that it has higher priority, however right after that
>> garbage collection kicks in and due to (probably) massive accumulated stack
>> it dies again...(it is a nice 875M image -_-)
>> ~~~~~~~~~
>> Smalltalk stack dump:
>> 0xff916d80 I SmalltalkImage>lowSpaceWatcher 0xb7674470: a(n)
>> SmalltalkImage
>> 0xf2ae8a2c s [] in SmalltalkImage>installLowSpaceWatcher
>> 0xf2ab50e0 s [] in BlockClosure>newProcess
>>
>> stack page bytes 4096 available headroom 3300 minimum unused headroom 3524
>>
>> (out of memory)
>> ~~~~~~~~~
>>
>> Is there some magic remedy for this?
>>
>> It seems that there is a small window between starting the image and it
>> crashing where I can do some little things; I managed to file out the most
>> critical package like this, however I don't know where else I was making
>> changes (day-ish of work)...
>>
>> The loop itself is announcement-based, so maybe that's why there is some
>> room for experimenting...
>>
>> Thanks,
>> Peter
>>
>
>
>
>

Reply via email to