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.