[Vm-dev] Re: [Pharo-project] Troubles with #flushCache and #run:with:in:

Wed Aug 10 19:31:47 UTC 2011

Hi Jorge,

    I've taken a look at this and its horrible. Basically the debug VM (no
optimization, asserts, and so fully debuggable) doesn't fail.  Only the
production and assert (-O1, asserts) show failuresa. But since this is in
TestRunner it is extremely difficult to compare the three VMs rto find out
where the difference lies becauee TestRunner runs things in a random order.

So could you do me a favour and construct an image where the tests are run
in a fixed order and show the error?  Please try and avoid the test that
asks for one's name.  I want to be able to run the image from the C debugger
without user intervention to analyse exactly what's going on.

Thanks in advance

On Mon, Aug 8, 2011 at 2:27 PM, Jorge Ressia <jorge.ressia at gmail.com> wrote:

> Hi Eliot,
>
> I put the image in http://dl.dropbox.com/u/14991225/Bifrost-Eliot.zip
> I am using VM.r2486.
>
> The object as method class is called HLMethod. I reverted the change
> on flushCache to have the previous implementation that breaks.
> If you run the tests in BFBehavioralMetaObjectTest, particularly the
> category "test - state write" several time at some point some tests
> are going to fail due to a DNU on GMDualCounter>>initialize.
>
> If you change the HLMethod>>flushCache to
>
> flushCache
>        <primitive: 116>
>
> This errors disappear.
>
> Sorry that I do not have a simpler example to reproduce the case but i
> tried to simplify it but could not reproduce it. I think that is has
> to do with the number of times that I change the compiled method at
> runtime.
>
> Cheers,
>
>
>
>
> On Mon, Aug 8, 2011 at 9:32 PM, Eliot Miranda <eliot.miranda at gmail.com>
> wrote:
> >
> > Hi Jorge,
> >
> > On Mon, Aug 8, 2011 at 12:20 PM, Jorge Ressia <jorge.ressia at gmail.com>
> wrote:
> >>
> >> Hi Eliot,
> >>
> >> I am experiencing the same problem as Lukas.
> >> I was having random DNU on replaced methods.
> >> I fixed the problem by flushing the cache on the compiled methods
> >> only, before I was flushing on the selector and on the class.
> >> It is not yet clear to me what is the right way of flushing the cache.
> >> Any explanation on that?
> >
> > Hmmm, no.  I would have thought that the right thing to do was to flush
> the selector.  Do you have an image containing a reproducible case I can
> test?
> >>
> >> I think that this goes along with
> >> http://code.google.com/p/pharo/issues/detail?id=2255
> >>
> http://forum.world.st/flushCache-with-MethoWrappers-in-CogVM-td3381310.html
> >>
> >> Eliot, if you need help debugging or testing a potential solution let
> >> me know, I have a bunch of test working on top of this.
> >>
> >> Cheers,
> >>
> >> On Mon, Jul 11, 2011 at 6:31 PM, Eliot Miranda <eliot.miranda at gmail.com>
> wrote:
> >> >
> >> > Hi All,
> >> >     I'm in touch with Lukas on this but have no time to address it
> right now.  worry not :)
> >> >
> >> > On Mon, Jul 11, 2011 at 3:05 AM, Mariano Martinez Peck <
> marianopeck at gmail.com> wrote:
> >> >>
> >> >>
> >> >> Maybe cc'ing VM mailing list can help.
> >> >>
> >> >> On Fri, Jul 1, 2011 at 9:32 AM, Lukas Renggli <renggli at gmail.com>
> wrote:
> >> >>>
> >> >>> Hi Eliot,
> >> >>>
> >> >>> I am using one of the latest VMs from your site (VM.r2434) and I
> >> >>> continue to have subtle problems with objects as methods
> (#flushCache,
> >> >>> #run:with:in:).
> >> >>>
> >> >>> The issue is that the test coverage in Pharo is kind of broken on
> Cog
> >> >>> for a long time already. It reports methods as not covered that are
> >> >>> clearly covered, and tests seem to randomly fail.
> >> >>>
> >> >>> I suspected that there is something wrong with the coverage code
> >> >>> itself. So I started to experiment with TestCoverage>>flushCache and
> >> >>> noticed that the current implementation
> >> >>>
> >> >>>    TestCoverage>>flushCache
> >> >>>        self reference methodSymbol flushCache
> >> >>>
> >> >>> performs not that well: The set of not covered methods is wrong and
> >> >>> many tests suddenly fail. If I replace it with
> >> >>>
> >> >>>    TestCoverage>>flushCache
> >> >>>        self reference actualClass flushCache
> >> >>>
> >> >>> I actually get accurate coverage information, but there are still a
> >> >>> few tests constantly failing. I tried to use all possible
> combinations
> >> >>> of #flushCache (also calling it on the compiled method), but only
> >> >>> flushing the cache on the class seems to work properly. So far so
> >> >>> good, but I really wonder what the correct way is to flush the
> cache?
> >> >>> :-)
> >> >>>
> >> >>> For my experiments I was using the package 'AST-Tests-Semantics'.
> This
> >> >>> is a small package with lots of test methods that cover each method
> >> >>> but one (RBSemanticAnnotationMisssing>>#isResumable). Now the "real"
> >> >>> problem is that when running these tests in coverage mode, the same
> 4
> >> >>> tests always fail:
> >> >>>
> >> >>>     RBSemanticTest>>testBlockScope
> >> >>>     RBSemanticTest>>testCascadeReceiver
> >> >>>     RBSemanticTest>>testClassVariableBinding
> >> >>>     RBSemanticTest>>testGlobalVariableBinding
> >> >>>
> >> >>> Not sure of how to debug that? Do you have an idea why these
> otherwise
> >> >>> passing tests suddenly fail? If you want to try to reproduce you can
> >> >>> use any Pharo image with the tests loaded, or use those that I used:
> >> >>>
> >> >>>
> http://jenkins.lukas-renggli.ch/job/Development/lastSuccessfulBuild/artifact/omnibrowser-tests/omnibrowser-tests.changes
> >> >>>
> http://jenkins.lukas-renggli.ch/job/Development/lastSuccessfulBuild/artifact/omnibrowser-tests/omnibrowser-tests.image
> >> >>>
> >> >>> Open the Test Runner, select 'AST-Tests-Semantics' and 'Run
> Coverage'.
> >> >>>
> >> >>> Any help or clarification would be appreciated :-)
> >> >>>
> >> >>> Lukas
> >> >>>
> >> >>> --
> >> >>> Lukas Renggli
> >> >>> www.lukas-renggli.ch
> >> >>>
> >> >>
> >> >>
> >> >>
> >> >> --
> >> >> Mariano
> >> >> http://marianopeck.wordpress.com
> >> >>
> >> >>
> >> >
> >> >
> >> >
> >> > --
> >> > best,
> >> > Eliot
> >> >
> >> >
> >>
> >>
> >>
> >> --
> >> Jorge Ressia
> >> www.jorgeressia.com
> >
> >
> >
> > --
> > best,
> > Eliot
> >
> >
>
>
>
> --
> Jorge Ressia
> www.jorgeressia.com
>

-- 
best,
Eliot
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.squeakfoundation.org/pipermail/vm-dev/attachments/20110810/e37dda80/attachment.htm