<
guillermopolito@gmail.com> wrote:
> Ok, so I did that, and have this. So the condense looks finished, but when
> returning to the UI thread, canvas is nil?
>
> Hmm, I think we should stop the UI thread also and spawn a new one after
> condensing...
>
> Error: MessageNotUnderstood: receiver of "finish" is nil
> UndefinedObject(Object)>>error:
> WorldState>>displayWorldSafely: in Block: [:t2 :t3 | ...
> BlockClosure>>cull:cull:
> BlockClosure>>ifError: in Block: [:t2 | t1 cull: t2 description cull: t2
> receiver]
> BlockClosure>>cull:
> MethodContext(ContextPart)>>handleSignal: in Block: [self
> exceptionHandlerBlock cull: exception]
> BlockClosure>>ensure:
> MethodContext(ContextPart)>>handleSignal:
> MessageNotUnderstood(Exception)>>signal
> UndefinedObject(Object)>>doesNotUnderstand: #finish
> WorldState>>displayWorld:submorphs:
>
> On Wed, Feb 20, 2013 at 12:15 PM, Marcus Denker <
marcus.denker@inria.fr>
> wrote:
>>
>>
>> On Feb 20, 2013, at 12:13 PM, Guillermo Polito <
guillermopolito@gmail.com>
>> wrote:
>>
>> Ok, I tried the following:
>>
>> - changed the become in #setSourcePointer: by an #at:put: in the method
>> dict
>> - before exporting the sources, I run the shutdown and after, I run the
>> startup lists.
>> - I ran the condense sources like
>>
>> [ Smalltalk condenseSources ] forkAt: Processor highestPriority.
>>
>>
>> Then, the export runs ok, but there is a crash in the CompiledMethod
>> class>>cleanUp
>>
>>
>> I think the cleanup is not necessary when condensing� it touches only
>> methods
>> that are *not* installed in classes.
>> We should remove that call from the condense method.
>>
>> Segmentation fault
>>
>>
>> Smalltalk stack dump:
>> 0xbffbe2d0 M ByteString class(String class)>new: 528605460: a(n)
>> ByteString class
>> 0xbffbe2f8 M ByteString(SequenceableCollection)>copyReplaceFrom:to:with:
>> 531139536: a(n) ByteString
>> 0xbffbe31c M ByteString(SequenceableCollection)>, 531139536: a(n)
>> ByteString
>> 0xbffbe33c M CompiledMethodTrailer>encode 570089224: a(n)
>> CompiledMethodTrailer
>> 0xbffbe35c M CompiledMethodTrailer>createMethod:class:header: 570089224:
>> a(n) CompiledMethodTrailer
>> 0xbffbe39c M CompiledMethod>copyWithTrailerBytes: 530925156: a(n)
>> CompiledMethod
>> 0xbffbe3bc M CompiledMethod>zapSourcePointer 530925156: a(n)
>> CompiledMethod
>> 0xbffbe3d4 M [] in CompiledMethod class>cleanUp 528604864: a(n)
>> CompiledMethod class
>>
>> On Wed, Feb 20, 2013 at 12:00 PM, Igor Stasenko <
siguctua@gmail.com>
>> wrote:
>>>
>>> i thinking that become is unnecessary,
>>> it can be just at:put: into method dictionary,
>>> so eventually all methods will be updated (after restarting permanent
>>> processes)
>>>
>>> On 20 February 2013 11:13, Guillermo Polito <
guillermopolito@gmail.com>
>>> wrote:
>>> > I summon Eliot :).
>>> >
>>> >
>>> > On Wed, Feb 20, 2013 at 11:03 AM, Marcus Denker
>>> > <
marcus.denker@inria.fr>
>>> > wrote:
>>> >>
>>> >>
>>> >> On Feb 20, 2013, at 11:01 AM, Guillermo Polito
>>> >> <
guillermopolito@gmail.com>
>>> >> wrote:
>>> >>
>>> >> 'cause you don't know if the method has trailer or not I think...
>>> >> There
>>> >> are empty trailers and trailers embedding source (directly in the
>>> >> image)...
>>> >> isn't it?
>>> >>
>>> >> Not for those methods installed in classes� we are updating an
>>> >> existing
>>> >> pointer here.
>>> >>
>>> >> Marcus
>>> >>
>>> >>
>>> >> On Wed, Feb 20, 2013 at 10:52 AM, Marcus Denker
>>> >> <
marcus.denker@inria.fr>
>>> >> wrote:
>>> >>>
>>> >>>
>>> >>> On Feb 20, 2013, at 10:45 AM, Guillermo Polito
>>> >>> <
guillermopolito@gmail.com> wrote:
>>> >>>
>>> >>> Hi!
>>> >>>
>>> >>> There is this bug open I was taking a look yesterday:
>>> >>>
>>> >>>
>>> >>>
>>> >>>
http://code.google.com/p/pharo/issues/detail?can=2&start=0&num=100&q=Milestone%3D2.0&colspec=ID%20Type%20Status%20Summary%20Milestone%20Difficulty&groupby=&sort=&id=7499
>>> >>>
>>> >>> The condense sources compacts the changes and source files, and adds
>>> >>> a
>>> >>> new method trailer to a compiled method with it's new source pointer.
>>> >>> In
>>> >>> order to do that, it does a #becomeForward: to the method.
>>> >>>
>>> >>> CompiledMethod>>setSourcePointer: srcPointer
>>> >>> "We can't change the trailer of existing method, since
>>> >>> it could have completely different format. Therefore we need to
>>> >>> generate a copy with new trailer, containing an scrPointer, and then
>>> >>> #become it"
>>> >>> | trailer copy |
>>> >>> trailer := CompiledMethodTrailer new sourcePointer: srcPointer.
>>> >>> copy := self copyWithTrailerBytes: trailer.
>>> >>> >>> self becomeForward: copy.
>>> >>> ^ copy
>>> >>>
>>> >>> So far, with simple methods, so good.
>>> >>>
>>> >>> However, there are cases, in which becoming the compiled method,
>>> >>> breaks
>>> >>> processes, sometimes getting a crash in the VM. For example:
>>> >>>
>>> >>> (Delay class>>#handleTimerEvent) setSourcePosition: 200 inFile: 1
>>> >>>
>>> >>> (ProcessorScheduler class>>#idleProcess) setSourcePosition: 200
>>> >>> inFile: 1
>>> >>>
>>> >>> My assumption is that the #becomeForward: of compiled methods do not
>>> >>> get
>>> >>> well with the stack mapping in the vm... But just guessing.
>>> >>>
>>> >>>
>>> >>> I wonder why we don't just update the pointer.
>>> >>> That is: we keep the method the same, rewrite the pointer, and
>>> >>> nothing
>>> >>> else.
>>> >>>
>>> >>> Marcus
>>> >>>
>>> >>
>>> >>
>>> >
>>>
>>>
>>>
>>> --
>>> Best regards,
>>> Igor Stasenko.
>>>
>>
>>
>