So, this (hacky) changeset does the trick. [ Smalltalk condenseSources ] forkAt: Processor highestPriority. works.. Resuming: - changed the becomeForward by an at:put: - a little hack/fix to serialize unicode chars in the sources file (Japanese environment) - removed the progress bar stuff from condenseChanges - before condensing process the shutdown list - after condensing process the startup list - do not cleanup methods - after processing the startuplist, kill current UIProcess and start a new one - run the condense changes in highest priority so it does not get preempted by inconsistent processes. On Wed, Feb 20, 2013 at 12:26 PM, Guillermo Polito < 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=Milesto...
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.