Pharo VM bug 11130

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
19 messages Options
Reply | Threaded
Open this post in threaded view
|

Pharo VM bug 11130

Max Leske
 
We could try reverting only those changes from the latest PharoVM code, build the VM ourselves and try again. I’d do it but I’m out of time at the moment.

Eliot, is revision 2640 available in any git repository? That might make cherry picking / reverting easier (at least for me it would :) )

Max


On 28.03.2014, at 00:13, [hidden email] wrote:

[Vm-dev] Pharo VM bug 11130

Reply | Threaded
Open this post in threaded view
|

Re: Pharo VM bug 11130

Eliot Miranda-2
 



On Fri, Mar 28, 2014 at 1:44 AM, Max Leske <[hidden email]> wrote:
 
We could try reverting only those changes from the latest PharoVM code, build the VM ourselves and try again. I’d do it but I’m out of time at the moment.

Eliot, is revision 2640 available in any git repository? That might make cherry picking / reverting easier (at least for me it would :) )

It's in svn, but that's not the right way to integrate.  Since the fixes are Smalltalk code the right way is to integrate in Monticello and generate a new VM.

<rant>But of course Pharo decided that git integration was more important than working on a perfectly good distributed version control system and now there is no easy way to move Smalltalk changes between Monticello and Monticello+git.  I'm unhappy about that.  But it's not my problem.  Anyone wanting to send changes back to me can either publish in Monticello or send me file-outs, etc, etc.  Anybody wanting my code can get it from http://source.squeak.org/VMMaker via Monticello.  Why the community would rather put up barriers to talking to each other so that it can attract the uninterested rest of the world is over my head.  I'm concentrating on Spur, which I hope will be useful to everyone in the community.</rant>
 

Max


On 28.03.2014, at 00:13, [hidden email] wrote:

[Vm-dev] Pharo VM bug 11130





--
best,
Eliot
Reply | Threaded
Open this post in threaded view
|

Re: Pharo VM bug 11130

timrowledge


On 28-03-2014, at 10:55 AM, Eliot Miranda <[hidden email]> wrote:

> <rant>But of course Pharo decided that git integration was more important than working on a perfectly good distributed version control system and now there is no easy way to move Smalltalk changes between Monticello and Monticello+git.  I'm unhappy about that.  But it's not my problem.  Anyone wanting to send changes back to me can either publish in Monticello or send me file-outs, etc, etc.  Anybody wanting my code can get it from http://source.squeak.org/VMMaker via Monticello.  Why the community would rather put up barriers to talking to each other so that it can attract the uninterested rest of the world is over my head.  I'm concentrating on Spur, which I hope will be useful to everyone in the community.</rant>
>

Hear-hear.

tim
--
tim Rowledge; [hidden email]; http://www.rowledge.org/tim
Strange OpCodes: DMK: Destroy Memory-protection Key


Reply | Threaded
Open this post in threaded view
|

Re: Pharo VM bug 11130

EstebanLM


On 28 Mar 2014, at 16:10, tim Rowledge <[hidden email]> wrote:

>
>
> On 28-03-2014, at 10:55 AM, Eliot Miranda <[hidden email]> wrote:
>
>> <rant>But of course Pharo decided that git integration was more important than working on a perfectly good distributed version control system and now there is no easy way to move Smalltalk changes between Monticello and Monticello+git.  I'm unhappy about that.  But it's not my problem.  Anyone wanting to send changes back to me can either publish in Monticello or send me file-outs, etc, etc.  Anybody wanting my code can get it from http://source.squeak.org/VMMaker via Monticello.  Why the community would rather put up barriers to talking to each other so that it can attract the uninterested rest of the world is over my head.  I'm concentrating on Spur, which I hope will be useful to everyone in the community.</rant>


well… I understand your frustration. But I promised you (and I meant to accomplish) that I was going to prepare a job who pushes back the monticello packages so they are available.
Sadly with all the running for releasing pharo3 I didn’t find the time yet… but next month I will have a few more time (just when I came back from my vacations).

Esteban

>>
>
> Hear-hear.
>
> tim
> --
> tim Rowledge; [hidden email]; http://www.rowledge.org/tim
> Strange OpCodes: DMK: Destroy Memory-protection Key
>
>

Reply | Threaded
Open this post in threaded view
|

Re: Pharo VM bug 11130

Eliot Miranda-2
 
On Fri, Mar 28, 2014 at 12:38 PM, Esteban Lorenzano <[hidden email]> wrote:

On 28 Mar 2014, at 16:10, tim Rowledge <[hidden email]> wrote:
>
> On 28-03-2014, at 10:55 AM, Eliot Miranda <[hidden email]> wrote:
>
>> <rant>But of course Pharo decided that git integration was more important than working on a perfectly good distributed version control system and now there is no easy way to move Smalltalk changes between Monticello and Monticello+git.  I'm unhappy about that.  But it's not my problem.  Anyone wanting to send changes back to me can either publish in Monticello or send me file-outs, etc, etc.  Anybody wanting my code can get it from http://source.squeak.org/VMMaker via Monticello.  Why the community would rather put up barriers to talking to each other so that it can attract the uninterested rest of the world is over my head.  I'm concentrating on Spur, which I hope will be useful to everyone in the community.</rant>


well… I understand your frustration. But I promised you (and I meant to accomplish) that I was going to prepare a job who pushes back the monticello packages so they are available.
Sadly with all the running for releasing pharo3 I didn’t find the time yet… but next month I will have a few more time (just when I came back from my vacations).

thanks Esteban, that will be _much_ appreciated!! 
--
best,
Eliot
Reply | Threaded
Open this post in threaded view
|

Re: Pharo VM bug 11130

Nicolas Cellier
 
While we are at ranting...
Even if you go thru the first tool hurdle (loading filetree in image and cloning a git repo is not that high),
there's another concern:
a lot of changes in the pharo-vm branch are purely aesthetical:
- a space has been added here and there
- or just the author changed...

That completely spoils the efficiency of MC merge with tons of false conflicts...
What do you use for integrating Eliot's changes? git tools?

Do you think that such kind of minor non functional changes will improve Pharo?
Or do you agree that gratuitous conflicts just result in more burden on the shoulders of a very restricted community?

I'd like to help Pharo, but please, help us to help you


2014-03-28 22:11 GMT+01:00 Eliot Miranda <[hidden email]>:
 
On Fri, Mar 28, 2014 at 12:38 PM, Esteban Lorenzano <[hidden email]> wrote:

On 28 Mar 2014, at 16:10, tim Rowledge <[hidden email]> wrote:
>
> On 28-03-2014, at 10:55 AM, Eliot Miranda <[hidden email]> wrote:
>
>> <rant>But of course Pharo decided that git integration was more important than working on a perfectly good distributed version control system and now there is no easy way to move Smalltalk changes between Monticello and Monticello+git.  I'm unhappy about that.  But it's not my problem.  Anyone wanting to send changes back to me can either publish in Monticello or send me file-outs, etc, etc.  Anybody wanting my code can get it from http://source.squeak.org/VMMaker via Monticello.  Why the community would rather put up barriers to talking to each other so that it can attract the uninterested rest of the world is over my head.  I'm concentrating on Spur, which I hope will be useful to everyone in the community.</rant>


well… I understand your frustration. But I promised you (and I meant to accomplish) that I was going to prepare a job who pushes back the monticello packages so they are available.
Sadly with all the running for releasing pharo3 I didn’t find the time yet… but next month I will have a few more time (just when I came back from my vacations).

thanks Esteban, that will be _much_ appreciated!! 
--
best,
Eliot


Reply | Threaded
Open this post in threaded view
|

Re: Pharo VM bug 11130

Stephan Eggermont-3
In reply to this post by Max Leske

Loading in a Moose image
VMMaker.oscog-eem.240.mcz
VMMaker.oscog-eem.236.mcz
VMMaker-oscog-LaurentLaffont.303.mcz

There are 12 methods that changed from 236 to 240 that are not the same in 303
(ignoring removed methods):
StackInterpreter>findClassOfMethod:forReceiver:
StackInterpreter>floatValueOf:
ObjectMemory>changeClassOf:to:
Cogit>declareCVarsIn:
StackInterpreter>isLiveContext:
InterpreterPrimitives>isInstanceOfClassByteString:
StackInterpreter>longPrintoop:
NewObjectMemory>okayOop:
NewObjectMemory>incrementalGC:

Stephan
Reply | Threaded
Open this post in threaded view
|

Re: Pharo VM bug 11130

Nicolas Cellier
 



2014-04-02 11:42 GMT+02:00 Stephan Eggermont <[hidden email]>:

Loading in a Moose image
VMMaker.oscog-eem.240.mcz
VMMaker.oscog-eem.236.mcz
VMMaker-oscog-LaurentLaffont.303.mcz

There are 12 methods that changed from 236 to 240 that are not the same in 303
(ignoring removed methods):
StackInterpreter>findClassOfMethod:forReceiver:
StackInterpreter>floatValueOf:
ObjectMemory>changeClassOf:to:
Cogit>declareCVarsIn:
StackInterpreter>isLiveContext:
InterpreterPrimitives>isInstanceOfClassByteString:
StackInterpreter>longPrintoop:
NewObjectMemory>okayOop:
NewObjectMemory>incrementalGC:

Stephan

Hmm, don't waste too much time.
All these methods are unchanged in github pharo-vm head revision (VMMaker-oscog-StefanMarr.313)
The cause must be completely different in latest pharo vms.

There are way too many changes to analyze if you want to diff with VMMaker.oscog branch
- changes related to using FileSystem instead of FileDirectory
- changes related to ephemerons
- changes related to NB
- ... ?
- many many false changes ( just formatting of methods - please don't do that! )

The right way to debug this is to have a VMSimulator working and be patient...
Reply | Threaded
Open this post in threaded view
|

Re: Pharo VM bug 11130

Stephan Eggermont-3
In reply to this post by Max Leske

Nicolas wrote:
>Hmm, don't waste too much time.
>All these methods are unchanged in github pharo-vm head revision (VMMaker-oscog-StefanMarr.313)
>The cause must be completely different in latest pharo vms.

Uhm, why? They haven’t changed.
Pharo vms 105 and later no longer crash, but all reliably show the bug.
And 236 is the last Squeak one to show the problem.

I might take a look at Esteban’s versions from the same time,
228 and 229
 
Stephan
Reply | Threaded
Open this post in threaded view
|

Re: Pharo VM bug 11130

Nicolas Cellier
 



2014-04-02 23:59 GMT+02:00 Stephan Eggermont <[hidden email]>:

Nicolas wrote:
>Hmm, don't waste too much time.
>All these methods are unchanged in github pharo-vm head revision (VMMaker-oscog-StefanMarr.313)
>The cause must be completely different in latest pharo vms.

Uhm, why? They haven’t changed.

Sorry, haven't changed means that there's no diff with the corrected version.
IOW, the fixes from Eliot have been integrated for a long time already.
You are seeing another symptom, probably another bug impacting the same code.
There are many diffs between pharo's and Eliot's branch, but not where you're looking at.

Pharo vms 105 and later no longer crash, but all reliably show the bug.
And 236 is the last Squeak one to show the problem.

I might take a look at Esteban’s versions from the same time,
228 and 229

Stephan

Reply | Threaded
Open this post in threaded view
|

Re: Pharo VM bug 11130

Nicolas Cellier
 
Good news,
I've managed to make your issue apparently vanish in Pharo3.0 VM.
For this, I:
- cleaned up unecessary differences with Eliot's VMMaker.oscog branch,
- removed unecessary changes ahead of VMMaker.oscog-eem.333 version (those stamped LucFabresse)
- carefully applied changes from VMMaker.oscog-eem.333 that were not applied
  Note that this version was marked as merged, which it was obviously not
  Please, if you do not fully merge, but just cherry pick some changes, it's better to not merge.
- upgraded to (merged) VMMaker.oscog-eem.335 because it fixes a snafu
- integrated the issues for which I emitted a pull request


I cannot tell which missing change exactly was the root cause, and I cannot dissect either, but I saw several + LiteralStart missing... Or it could be related to cogit method/block native code generation...
The changes are most probably here
https://github.com/nicolas-cellier-aka-nice/pharo-vm/commit/af718618eee516d15c0b362123e3a77c8b6fd2e8

Bad news,
the structures at beginning of src/cm/cogit.c are generated out of order, and I didn't find the cause yet.
Once solved, I think my branch should be carefully reviewed and integrated.



2014-04-03 4:13 GMT+02:00 Nicolas Cellier <[hidden email]>:



2014-04-02 23:59 GMT+02:00 Stephan Eggermont <[hidden email]>:


Nicolas wrote:
>Hmm, don't waste too much time.
>All these methods are unchanged in github pharo-vm head revision (VMMaker-oscog-StefanMarr.313)
>The cause must be completely different in latest pharo vms.

Uhm, why? They haven’t changed.

Sorry, haven't changed means that there's no diff with the corrected version.
IOW, the fixes from Eliot have been integrated for a long time already.
You are seeing another symptom, probably another bug impacting the same code.
There are many diffs between pharo's and Eliot's branch, but not where you're looking at.

Pharo vms 105 and later no longer crash, but all reliably show the bug.
And 236 is the last Squeak one to show the problem.

I might take a look at Esteban’s versions from the same time,
228 and 229

Stephan


Reply | Threaded
Open this post in threaded view
|

Re: Pharo VM bug 11130

Nicolas Cellier
 

2014-04-06 22:29 GMT+02:00 Nicolas Cellier <[hidden email]>:
Good news,
I've managed to make your issue apparently vanish in Pharo3.0 VM.
For this, I:
- cleaned up unecessary differences with Eliot's VMMaker.oscog branch,
- removed unecessary changes ahead of VMMaker.oscog-eem.333 version (those stamped LucFabresse)
- carefully applied changes from VMMaker.oscog-eem.333 that were not applied
  Note that this version was marked as merged, which it was obviously not
  Please, if you do not fully merge, but just cherry pick some changes, it's better to not merge.
- upgraded to (merged) VMMaker.oscog-eem.335 because it fixes a snafu
- integrated the issues for which I emitted a pull request


I cannot tell which missing change exactly was the root cause, and I cannot dissect either, but I saw several + LiteralStart missing... Or it could be related to cogit method/block native code generation...
The changes are most probably here
https://github.com/nicolas-cellier-aka-nice/pharo-vm/commit/af718618eee516d15c0b362123e3a77c8b6fd2e8

Bad news,
the structures at beginning of src/cm/cogit.c are generated out of order, and I didn't find the cause yet.
Once solved, I think my branch should be carefully reviewed and integrated.


Haha! this is Class class>>superclassOrder: which break things...
The order of structures passed on input was mostly good but ruined on output...

The Squeak ChangeSet class>>superclassOrder: does not convert the list of classes asSet, thus somehow preserves provided order.
The Pharo version does not take so much care it seems...
Apparently the method was changed again in Pharo3.0, but neither does it preserve order.

After fixing it, compilation went well...



2014-04-03 4:13 GMT+02:00 Nicolas Cellier <[hidden email]>:




2014-04-02 23:59 GMT+02:00 Stephan Eggermont <[hidden email]>:


Nicolas wrote:
>Hmm, don't waste too much time.
>All these methods are unchanged in github pharo-vm head revision (VMMaker-oscog-StefanMarr.313)
>The cause must be completely different in latest pharo vms.

Uhm, why? They haven’t changed.

Sorry, haven't changed means that there's no diff with the corrected version.
IOW, the fixes from Eliot have been integrated for a long time already.
You are seeing another symptom, probably another bug impacting the same code.
There are many diffs between pharo's and Eliot's branch, but not where you're looking at.

Pharo vms 105 and later no longer crash, but all reliably show the bug.
And 236 is the last Squeak one to show the problem.

I might take a look at Esteban’s versions from the same time,
228 and 229

Stephan



Reply | Threaded
Open this post in threaded view
|

Re: Pharo VM bug 11130

Stephan Eggermont-3
In reply to this post by Max Leske
 
(Nicolas, do you use fogbugz?)
Igor wrote on the issue tracker:

So, i tried to build Nicolas'es commit 
c631221ce2fe993c611dc7bced0d50876a3928c5

and after fixing #superClassOrder: (by simply removing a call to it), ive managed to build VM.
However this code still fails:

1 to: 1000 do: [ :i |
        | string |
        Transcript show: 'Iteration '; show: i; cr.
        1 timesRepeat: [
            (string := String new: 1000 withAll: $a)
                reversed.
        ].
    ].

(you need Transcript window open for it to fail)
Edited by Igor Stasenko 4/11/2014 (Today) 4:29 PM Edit 
-- built a debug version of VM, reveals no assertions, nothing
Reply | Threaded
Open this post in threaded view
|

Re: Pharo VM bug 11130

Eliot Miranda-2
 
Hi Stephan,

What happens if you use "-cogminjumps 10000" on the command line?  This flag determines how many times an interpreted method needs to loop for the VM to decide to convert the interpreted activation containing the loop into a machine-code activation.  If there is a bug in bytecode-to-machine-code pc mapping the VM can crash.  I wonder whether that could be the issue here.


On Fri, Apr 11, 2014 at 11:43 AM, Stephan Eggermont <[hidden email]> wrote:
 
(Nicolas, do you use fogbugz?)
Igor wrote on the issue tracker:

So, i tried to build Nicolas'es commit 
c631221ce2fe993c611dc7bced0d50876a3928c5

and after fixing #superClassOrder: (by simply removing a call to it), ive managed to build VM.
However this code still fails:

1 to: 1000 do: [ :i |
        | string |
        Transcript show: 'Iteration '; show: i; cr.
        1 timesRepeat: [
            (string := String new: 1000 withAll: $a)
                reversed.
        ].
    ].

(you need Transcript window open for it to fail)
Edited by Igor Stasenko 4/11/2014 (Today) 4:29 PM Edit 
-- built a debug version of VM, reveals no assertions, nothing




--
best,
Eliot
Reply | Threaded
Open this post in threaded view
|

Re: Pharo VM bug 11130

Nicolas Cellier
In reply to this post by Stephan Eggermont-3
 

2014-04-11 20:43 GMT+02:00 Stephan Eggermont <[hidden email]>:
 
(Nicolas, do you use fogbugz?)
Igor wrote on the issue tracker:

So, i tried to build Nicolas'es commit 
c631221ce2fe993c611dc7bced0d50876a3928c5

and after fixing #superClassOrder: (by simply removing a call to it), ive managed to build VM.
However this code still fails:

1 to: 1000 do: [ :i |
        | string |
        Transcript show: 'Iteration '; show: i; cr.
        1 timesRepeat: [
            (string := String new: 1000 withAll: $a)
                reversed.
        ].
    ].

(you need Transcript window open for it to fail)
Edited by Igor Stasenko 4/11/2014 (Today) 4:29 PM Edit 
-- built a debug version of VM, reveals no assertions, nothing


Ahem... This works on my mac at least.
Transcript opened or not, the iterations always go to the 1000th without MessageNotUnderstood
Reply | Threaded
Open this post in threaded view
|

Re: Pharo VM bug 11130

Nicolas Cellier
 

2014-04-11 23:29 GMT+02:00 Nicolas Cellier <[hidden email]>:

2014-04-11 20:43 GMT+02:00 Stephan Eggermont <[hidden email]>:
 
(Nicolas, do you use fogbugz?)

I forgot to answer:
YES, I use fogbugz, and I starred this issue.
But for some reason, the only things I regularly see coming in my inbox are those automated Monkey editions.
Either I mechanically removed a human edition in a flow of monkeys, or I did not receive anything human...

 
Igor wrote on the issue tracker:

So, i tried to build Nicolas'es commit 
c631221ce2fe993c611dc7bced0d50876a3928c5

and after fixing #superClassOrder: (by simply removing a call to it), ive managed to build VM.
However this code still fails:


1 to: 1000 do: [ :i |
        | string |
        Transcript show: 'Iteration '; show: i; cr.
        1 timesRepeat: [
            (string := String new: 1000 withAll: $a)
                reversed.
        ].
    ].

(you need Transcript window open for it to fail)
Edited by Igor Stasenko 4/11/2014 (Today) 4:29 PM Edit 
-- built a debug version of VM, reveals no assertions, nothing


Ahem... This works on my mac at least.
Transcript opened or not, the iterations always go to the 1000th without MessageNotUnderstood

Reply | Threaded
Open this post in threaded view
|

Re: Pharo VM bug 11130

Nicolas Cellier
 



2014-04-11 23:43 GMT+02:00 Nicolas Cellier <[hidden email]>:

2014-04-11 23:29 GMT+02:00 Nicolas Cellier <[hidden email]>:


2014-04-11 20:43 GMT+02:00 Stephan Eggermont <[hidden email]>:
 
(Nicolas, do you use fogbugz?)

I forgot to answer:
YES, I use fogbugz, and I starred this issue.
But for some reason, the only things I regularly see coming in my inbox are those automated Monkey editions.
Either I mechanically removed a human edition in a flow of monkeys, or I did not receive anything human...

 
Igor wrote on the issue tracker:

So, i tried to build Nicolas'es commit 
c631221ce2fe993c611dc7bced0d50876a3928c5

and after fixing #superClassOrder: (by simply removing a call to it), ive managed to build VM.
However this code still fails:


1 to: 1000 do: [ :i |
        | string |
        Transcript show: 'Iteration '; show: i; cr.
        1 timesRepeat: [
            (string := String new: 1000 withAll: $a)
                reversed.
        ].
    ].

(you need Transcript window open for it to fail)
Edited by Igor Stasenko 4/11/2014 (Today) 4:29 PM Edit 
-- built a debug version of VM, reveals no assertions, nothing


Ahem... This works on my mac at least.
Transcript opened or not, the iterations always go to the 1000th without MessageNotUnderstood


For those not in fogbugz, It works on my mac not because I applied the delta with Eliot's branch...
But because I have an older compiler:

I'm on MacOsX 10.6.8 with Xcode Version 3.2.6 and
i686-apple-darwin10-gcc-4.2.1 (GCC) 4.2.1 (Apple Inc. build 5666) (dot 3)
Reply | Threaded
Open this post in threaded view
|

Re: Pharo VM bug 11130

Stephan Eggermont-3
In reply to this post by Max Leske

Nicolas wrote
>YES, I use fogbugz, and I starred this issue.
>But for some reason, the only things I regularly see coming in my inbox are those automated Monkey editions.
>Either I mechanically removed a human edition in a flow of monkeys, or I did not receive anything human…

Known issue with Fogbugz, I’m afraid. Monkey has a separate flow.
To get notified of non-monkey changes, you need to add yourself to the subscriber list.
I added you to the list.

Stephan

p.s. Eliot, you are not subscribed
Reply | Threaded
Open this post in threaded view
|

Re: Pharo VM bug 11130

Ben Coman
In reply to this post by Nicolas Cellier
 
Nicolas Cellier wrote:
 




2014-04-11 23:29 GMT+02:00 Nicolas Cellier <[hidden email]>:

2014-04-11 20:43 GMT+02:00 Stephan Eggermont <[hidden email]>:
 
(Nicolas, do you use fogbugz?)

I forgot to answer:
YES, I use fogbugz, and I starred this issue.
But for some reason, the only things I regularly see coming in my inbox are those automated Monkey editions.
Either I mechanically removed a human edition in a flow of monkeys, or I did not receive anything human...

 
Igor wrote on the issue tracker:

So, i tried to build Nicolas'es commit 
c631221ce2fe993c611dc7bced0d50876a3928c5

and after fixing #superClassOrder: (by simply removing a call to it), ive managed to build VM.
However this code still fails:


1 to: 1000 do: [ :i |
        | string |
        Transcript show: 'Iteration '; show: i; cr.
        1 timesRepeat: [
            (string := String new: 1000 withAll: $a)
                reversed.
        ].
    ].

(you need Transcript window open for it to fail)
Edited by Igor Stasenko 4/11/2014 (Today) 4:29 PM Edit 
-- built a debug version of VM, reveals no assertions, nothing


Ahem... This works on my mac at least.
Transcript opened or not, the iterations always go to the 1000th without MessageNotUnderstood

Just fyi since it caught me out. Starring the issue is not subscribing to it. That is beneath the sidebar.
cheers -ben