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