Smalltalk › Cincom › VisualWorks

Question about Behavior>>flushVMmethodCacheEntriesFor:

_‹ Previous Topic Next Topic _›

Classic

List

Threaded

22 messages Options

Ladislav Lenart

Question about Behavior>>flushVMmethodCacheEntriesFor:

Hi,

just yesterday me and my colleague successfully solved a problem with
seg-faulting VW7.3 image when running more test cases at once. All these
tests were compiling methods, modifying method dictionaries (via
#at:put:) and then sending these new or modified methods.

The strange on this was, that when we ran only one test, the image never
crashed (and the test was green). When we ran two tests, image crashed
often but not always. When we ran more of them, it crashed always.
Because of this pattern of behavior, we thought that SUnitToo uses more
processes but this prooved wrong. Finally we took a look at
MethodWrappers and found that each wrapper immediately after its install
(or uninstall) calls method #flushVMmethodCacheEntriesFor:. We put call
to this method to one place (just after the #at:put:) and suddenly all
works fine.

What I don't understand is the reason why the image crashed (in
scavenging phase of GC). Method caches were not in sync with current
state of image but I see no reason why the image should crash (I would
expect different methods to be sent, but not this).

Could someone explain this to me in more detail please?

Finally I would like to know if there is a way (other methods for
example?) how to prevent the following actions to be written to system
changes:
#addSelector:withMethod:category:
#compile:classified:
#removeSelector:

Thanks,

Ladislav Lenart

Charles A. Monteiro-2

Re: Question about Behavior>>flushVMmethodCacheEntriesFor:

Ladislav:

The problem is that somewhere down the line from these you get calls to
ChangeSet. You can track this down and depending on what you want to do
you may be able to call something more specific. However, probably the
easiest thing may be to just tell the ChangeSet not to "broadcastChanges"
i.e. there is a SharedVar that is by default set to true.

The API provided is:

ChangeSet ignoreChangesWhile: aBlock

where in the block you are doing your dynamic behavior changes.

hth,

-Charles

> Finally I would like to know if there is a way (other methods for
> example?) how to prevent the following actions to be written to system
> changes:
> #addSelector:withMethod:category:
> #compile:classified:
> #removeSelector:
>

On Tue, 28 Feb 2006 03:43:04 -0500, Ladislav Lenart <[hidden email]>
wrote:

> Hi,
>
> just yesterday me and my colleague successfully solved a problem with
> seg-faulting VW7.3 image when running more test cases at once. All these
> tests were compiling methods, modifying method dictionaries (via
> #at:put:) and then sending these new or modified methods.
>
> The strange on this was, that when we ran only one test, the image never
> crashed (and the test was green). When we ran two tests, image crashed
> often but not always. When we ran more of them, it crashed always.
> Because of this pattern of behavior, we thought that SUnitToo uses more
> processes but this prooved wrong. Finally we took a look at
> MethodWrappers and found that each wrapper immediately after its install
> (or uninstall) calls method #flushVMmethodCacheEntriesFor:. We put call
> to this method to one place (just after the #at:put:) and suddenly all
> works fine.
>
> What I don't understand is the reason why the image crashed (in
> scavenging phase of GC). Method caches were not in sync with current
> state of image but I see no reason why the image should crash (I would
> expect different methods to be sent, but not this).
>
> Could someone explain this to me in more detail please?
>
> Finally I would like to know if there is a way (other methods for
> example?) how to prevent the following actions to be written to system
> changes:
> #addSelector:withMethod:category:
> #compile:classified:
> #removeSelector:
>
> Thanks,
>
> Ladislav Lenart

--
Charles A. Monteiro

Alan Knight-2

Re: Question about Behavior>>flushVMmethodCacheEntriesFor:

I wouldn't turn off notification, you're likely to confuse a bunch of other structures. Besides, it's relatively easy to compile without logging. For example, with Store loaded, see ClassDescription>>compileWithoutStoringSource:classified:. That's a shortcut used to improve Store source load times by compiling everything, then doing all of the logging at once. But in general, the part that compiles is separate from the part that logs. For another example, see ClassDescription>>compile:classified:notifying:attributes:environment:
It should be pretty clear there which part is compiling and which part is logging.

At 09:46 AM 2/28/2006, Charles A. Monteiro wrote:

>Ladislav:
>
>The problem is that somewhere down the line from these you get calls to
>ChangeSet. You can track this down and depending on what you want to do
>you may be able to call something more specific. However, probably the
>easiest thing may be to just tell the ChangeSet not to "broadcastChanges"
>i.e. there is a SharedVar that is by default set to true.
>
>The API provided is:
>
>ChangeSet ignoreChangesWhile: aBlock
>
>where in the block you are doing your dynamic behavior changes.
>
>hth,
>
>-Charles
>
>
>>Finally I would like to know if there is a way (other methods for
>>example?) how to prevent the following actions to be written to system
>>changes:
>> #addSelector:withMethod:category:
>> #compile:classified:
>> #removeSelector:
>
>
>On Tue, 28 Feb 2006 03:43:04 -0500, Ladislav Lenart <[hidden email]>
>wrote:
>
>>Hi,
>>
>>just yesterday me and my colleague successfully solved a problem with
>>seg-faulting VW7.3 image when running more test cases at once. All these
>>tests were compiling methods, modifying method dictionaries (via
>>#at:put:) and then sending these new or modified methods.
>>
>>The strange on this was, that when we ran only one test, the image never
>>crashed (and the test was green). When we ran two tests, image crashed
>>often but not always. When we ran more of them, it crashed always.
>>Because of this pattern of behavior, we thought that SUnitToo uses more
>>processes but this prooved wrong. Finally we took a look at
>>MethodWrappers and found that each wrapper immediately after its install
>>(or uninstall) calls method #flushVMmethodCacheEntriesFor:. We put call
>>to this method to one place (just after the #at:put:) and suddenly all
>>works fine.
>>
>>What I don't understand is the reason why the image crashed (in
>>scavenging phase of GC). Method caches were not in sync with current
>>state of image but I see no reason why the image should crash (I would
>>expect different methods to be sent, but not this).
>>
>>Could someone explain this to me in more detail please?
>>
>>Finally I would like to know if there is a way (other methods for
>>example?) how to prevent the following actions to be written to system
>>changes:
>> #addSelector:withMethod:category:
>> #compile:classified:
>> #removeSelector:
>>
>>Thanks,
>>
>>Ladislav Lenart
>
>
>
>--
>Charles A. Monteiro

--
Alan Knight [|], Cincom Smalltalk Development
[hidden email]
[hidden email]
http://www.cincom.com/smalltalk

"The Static Typing Philosophy: Make it fast. Make it right. Make it run." - Niall Ross

Charles A. Monteiro-2

Re: Question about Behavior>>flushVMmethodCacheEntriesFor:

yes, it depends on what he is doing. If creating classes and methods at
runtime one may not care. However, if you want to co-exist with the VW IDE
i.e. in dev mode you will certainly care. The following are the dependents
of ChangeSet in my image, note that because the printStrings for some of
these are quite involved I simplified by just collecting the associated
"instanceBehavior(s)"

#(Parcel Override Refactory.Browser.RefactoryChangeManager ChangeHistorian
NamespaceChangeListener Store.XMainChangeSet MiniChangeSetManager
Refactory.Browser.PundleNavigatorPart Refactory.Browser.ClassNavigatorPart
Refactory.Browser.MethodNavigatorPart Refactory.Browser.BrowserCodeTool
Refactory.Browser.MethodNavigatorPart Refactory.Browser.BrowserCodeTool
Refactory.Browser.SharedVariableProtocolNavigatorPart
Refactory.Browser.SharedVariableNavigatorPart
Refactory.Browser.MethodNavigatorPart Refactory.Browser.BrowserCodeTool)

these all seem to be very much about the IDE. Having said that I think I
will check out what the NamespaceChangeListener does.

-Charles
On Tue, 28 Feb 2006 13:07:13 -0500, Alan Knight <[hidden email]> wrote:

> I wouldn't turn off notification, you're likely to confuse a bunch of
> other structures. Besides, it's relatively easy to compile without
> logging. For example, with Store loaded, see
> ClassDescription>>compileWithoutStoringSource:classified:. That's a
> shortcut used to improve Store source load times by compiling
> everything, then doing all of the logging at once. But in general, the
> part that compiles is separate from the part that logs. For another
> example, see
> ClassDescription>>compile:classified:notifying:attributes:environment:
> It should be pretty clear there which part is compiling and which part
> is logging.
>
> At 09:46 AM 2/28/2006, Charles A. Monteiro wrote:
>> Ladislav:
>>
>> The problem is that somewhere down the line from these you get calls to
>> ChangeSet. You can track this down and depending on what you want to do
>> you may be able to call something more specific. However, probably the
>> easiest thing may be to just tell the ChangeSet not to
>> "broadcastChanges"
>> i.e. there is a SharedVar that is by default set to true.
>>
>> The API provided is:
>>
>> ChangeSet ignoreChangesWhile: aBlock
>>
>> where in the block you are doing your dynamic behavior changes.
>>
>> hth,
>>
>> -Charles
>>
>>
>>> Finally I would like to know if there is a way (other methods for
>>> example?) how to prevent the following actions to be written to system
>>> changes:
>>> #addSelector:withMethod:category:
>>> #compile:classified:
>>> #removeSelector:
>>
>>
>> On Tue, 28 Feb 2006 03:43:04 -0500, Ladislav Lenart <[hidden email]>
>> wrote:
>>
>>> Hi,
>>>
>>> just yesterday me and my colleague successfully solved a problem with
>>> seg-faulting VW7.3 image when running more test cases at once. All
>>> these
>>> tests were compiling methods, modifying method dictionaries (via
>>> #at:put:) and then sending these new or modified methods.
>>>
>>> The strange on this was, that when we ran only one test, the image
>>> never
>>> crashed (and the test was green). When we ran two tests, image crashed
>>> often but not always. When we ran more of them, it crashed always.
>>> Because of this pattern of behavior, we thought that SUnitToo uses more
>>> processes but this prooved wrong. Finally we took a look at
>>> MethodWrappers and found that each wrapper immediately after its
>>> install
>>> (or uninstall) calls method #flushVMmethodCacheEntriesFor:. We put call
>>> to this method to one place (just after the #at:put:) and suddenly all
>>> works fine.
>>>
>>> What I don't understand is the reason why the image crashed (in
>>> scavenging phase of GC). Method caches were not in sync with current
>>> state of image but I see no reason why the image should crash (I would
>>> expect different methods to be sent, but not this).
>>>
>>> Could someone explain this to me in more detail please?
>>>
>>> Finally I would like to know if there is a way (other methods for
>>> example?) how to prevent the following actions to be written to system
>>> changes:
>>> #addSelector:withMethod:category:
>>> #compile:classified:
>>> #removeSelector:
>>>
>>> Thanks,
>>>
>>> Ladislav Lenart
>>
>>
>>
>> --
>> Charles A. Monteiro
>
> --
> Alan Knight [|], Cincom Smalltalk Development
> [hidden email]
> [hidden email]
> http://www.cincom.com/smalltalk
>
> "The Static Typing Philosophy: Make it fast. Make it right. Make it
> run." - Niall Ross

--
Charles A. Monteiro

Ladislav Lenart

Re: Question about Behavior>>flushVMmethodCacheEntriesFor:

Charles A. Monteiro wrote:

> yes, it depends on what he is doing. If creating classes and methods
> at runtime one may not care. However, if you want to co-exist with
> the VW IDE i.e. in dev mode you will certainly care. The following
> are the dependents of ChangeSet in my image, note that because the
> printStrings for some of these are quite involved I simplified by
> just collecting the associated "instanceBehavior(s)"

Well, I am doing all this in development image in unit tests, so I would
like to coexist with browsers but in the same time I don't want these
changes made in tests written to the ChangeSet...

And what about my other question, there is really no one out there who
can explain that to me? :-)

Ladislav Lenart

>
> #(Parcel Override Refactory.Browser.RefactoryChangeManager
> ChangeHistorian NamespaceChangeListener Store.XMainChangeSet
> MiniChangeSetManager Refactory.Browser.PundleNavigatorPart
> Refactory.Browser.ClassNavigatorPart
> Refactory.Browser.MethodNavigatorPart
> Refactory.Browser.BrowserCodeTool
> Refactory.Browser.MethodNavigatorPart
> Refactory.Browser.BrowserCodeTool
> Refactory.Browser.SharedVariableProtocolNavigatorPart
> Refactory.Browser.SharedVariableNavigatorPart
> Refactory.Browser.MethodNavigatorPart Refactory.Browser.BrowserCodeTool)
>
> these all seem to be very much about the IDE. Having said that I think
> I will check out what the NamespaceChangeListener does.
>
> -Charles
> On Tue, 28 Feb 2006 13:07:13 -0500, Alan Knight <[hidden email]> wrote:
>
>> I wouldn't turn off notification, you're likely to confuse a bunch
>> of other structures. Besides, it's relatively easy to compile
>> without logging. For example, with Store loaded, see
>> ClassDescription>>compileWithoutStoringSource:classified:. That's a
>> shortcut used to improve Store source load times by compiling
>> everything, then doing all of the logging at once. But in general,
>> the part that compiles is separate from the part that logs. For
>> another example, see
>> ClassDescription>>compile:classified:notifying:attributes:environment:
>> It should be pretty clear there which part is compiling and which
>> part is logging.
>>
>> At 09:46 AM 2/28/2006, Charles A. Monteiro wrote:
>>
>>> Ladislav:
>>>
>>> The problem is that somewhere down the line from these you get calls to
>>> ChangeSet. You can track this down and depending on what you want to do
>>> you may be able to call something more specific. However, probably the
>>> easiest thing may be to just tell the ChangeSet not to
>>> "broadcastChanges"
>>> i.e. there is a SharedVar that is by default set to true.
>>>
>>> The API provided is:
>>>
>>> ChangeSet ignoreChangesWhile: aBlock
>>>
>>> where in the block you are doing your dynamic behavior changes.
>>>
>>> hth,
>>>
>>> -Charles
>>>
>>>
>>>> Finally I would like to know if there is a way (other methods for
>>>> example?) how to prevent the following actions to be written to system
>>>> changes:
>>>> #addSelector:withMethod:category:
>>>> #compile:classified:
>>>> #removeSelector:
>>>
>>>
>>>
>>> On Tue, 28 Feb 2006 03:43:04 -0500, Ladislav Lenart
>>> <[hidden email]>
>>> wrote:
>>>
>>>> Hi,
>>>>
>>>> just yesterday me and my colleague successfully solved a problem with
>>>> seg-faulting VW7.3 image when running more test cases at once. All
>>>> these
>>>> tests were compiling methods, modifying method dictionaries (via
>>>> #at:put:) and then sending these new or modified methods.
>>>>
>>>> The strange on this was, that when we ran only one test, the image
>>>> never
>>>> crashed (and the test was green). When we ran two tests, image crashed
>>>> often but not always. When we ran more of them, it crashed always.
>>>> Because of this pattern of behavior, we thought that SUnitToo uses
>>>> more
>>>> processes but this prooved wrong. Finally we took a look at
>>>> MethodWrappers and found that each wrapper immediately after its
>>>> install
>>>> (or uninstall) calls method #flushVMmethodCacheEntriesFor:. We put
>>>> call
>>>> to this method to one place (just after the #at:put:) and suddenly all
>>>> works fine.
>>>>
>>>> What I don't understand is the reason why the image crashed (in
>>>> scavenging phase of GC). Method caches were not in sync with current
>>>> state of image but I see no reason why the image should crash (I would
>>>> expect different methods to be sent, but not this).
>>>>
>>>> Could someone explain this to me in more detail please?
>>>>
>>>> Finally I would like to know if there is a way (other methods for
>>>> example?) how to prevent the following actions to be written to system
>>>> changes:
>>>> #addSelector:withMethod:category:
>>>> #compile:classified:
>>>> #removeSelector:
>>>>
>>>> Thanks,
>>>>
>>>> Ladislav Lenart
>>>
>>>
>>>
>>>
>>> --
>>> Charles A. Monteiro
>>
>>
>> --
>> Alan Knight [|], Cincom Smalltalk Development
>> [hidden email]
>> [hidden email]
>> http://www.cincom.com/smalltalk
>>
>> "The Static Typing Philosophy: Make it fast. Make it right. Make it
>> run." - Niall Ross
>
>
>
>

Steven Kelly

RE: Question about Behavior>>flushVMmethodCacheEntriesFor:

In reply to this post by Ladislav Lenart

> And what about my other question, there is really no one
> out there who can explain that to me? :-)

I think it would be safe to assume that the percentage of the world's
population who can _explain_ that is around 0.000000015%. We've enjoyed
the intricacies of flushVMmethodCache* for around 13 years, and I can't
claim to fully understand it. The only way to do that is read the VM
source code (oh, and get a PhD or greater experience in VMs, PICs etc.).
In an attempt to keep what's left of my sanity and productivity, I've
tried to avoid doing either.

I would suspect the cause is a bug, most probably introduced with all
the wonderful VM speed optimizations we've been enjoying. A simplistic
VM would probably behave like you imagined, and simply run the old
version; VW's VM is one of the most powerful out there, and far from
simplistic. "Normal" use of VW won't hit the problem, because both image
and VM are pretty aggressive about throwing away the whole VMmethodCache
on the slightest change.

Given what happens when you leave old stuff in the cache - as you have
seen - that's perhaps understandable. flushVMmethodCache tends to be
pretty expensive, though, so if you have an application that invokes
code that invokes the flush (e.g. recompiling a class), it can mount up.
Our database app was doing that several hundred times on each commit,
which became the major factor. We tried to set things up so it was
called only once at the end (we knew no methods from the classes in
question would be called in the interim). Oddly, this didn't work: the
image did the calls, but the cache for the classes in question was not
flushed. Eliot tried to explain this, but I think we didn't fully
understand each other - although I certainly learned a lot. In the end,
we rigged things so our classes didn't need to flush their cache at all,
made the updates to them by our own shortcut method that avoided the
flushVMmethodCache stuff, and everything went a lot faster and just
worked.

That experience was back in 3.0, and many things have changed in the
VMmethodCache since then. My suggestion would be two-fold:

1) create a minimal test case that exhibits the crash, and send it to
Cincom support
2) if you only need this for tests, simply call flushVMmethodCache* at
appropriate places (as you have started doing). That's what you're meant
to be doing, and I can't see any way of avoiding it if you're really
changing the method dictionary.

HTH - and if it leads to an AR, I'd be grateful to be added to the
notification list, since problems in flushVMmethodCache* might bite us
too.

Steve

> >>> On Tue, 28 Feb 2006 03:43:04 -0500, Ladislav Lenart
> >>> <[hidden email]>
> >>> wrote:
> >>>
> >>>> Hi,
> >>>>
> >>>> just yesterday me and my colleague successfully solved
> >>>> a problem with seg-faulting VW7.3 image when running
> >>>> more test cases at once. All these tests were
> >>>> compiling methods, modifying method dictionaries (via
> >>>> #at:put:) and then sending these new or modified methods.
> >>>>
> >>>> The strange on this was, that when we ran only one test,
> >>>> never the imagecrashed (and the test was green). When
> >>>> we ran two tests, image crashed
> >>>> often but not always. When we ran more of them, it
> >>>> crashed always. Because of this pattern of behavior,
> >>>> we thought that SUnitToo uses more
> >>>> processes but this prooved wrong. Finally we took a look at
> >>>> MethodWrappers and found that each wrapper immediately
> >>>> after its install (or uninstall) calls method
> >>>> #flushVMmethodCacheEntriesFor:. We put call
> >>>> to this method to one place (just after the #at:put:)
> >>>> and suddenly all works fine.
> >>>>
> >>>> What I don't understand is the reason why the image crashed (in
> >>>> scavenging phase of GC). Method caches were not in sync with
> >>>> current state of image but I see no reason why the image should
> >>>> crash (I would expect different methods to be sent, but
> >>>> not this).
> >>>>
> >>>> Could someone explain this to me in more detail please?

Reinout Heeck

Re: Question about Behavior>>flushVMmethodCacheEntriesFor:

Steven Kelly wrote:
>
> 1) create a minimal test case that exhibits the crash, and send it to
> Cincom support

Pretty please.
This probably involves quite a bit of effort from your side but in the past we
have enabled Eliot to flush out GC bugs that confounded him. A repeatable
case provides the leverage to get it fixed.

'Pretty please' because we are currently suffering VM crashes in mmScavenge in
one of our projects, the more datapoints others can offer us the more we are
helped :-)

R
-

Ladislav Lenart

Re: Question about Behavior>>flushVMmethodCacheEntriesFor:

In reply to this post by Steven Kelly

Steven Kelly wrote:

And what about my other question, there is really no one 
out there who can explain that to me? :-)


I think it would be safe to assume that the percentage of the world's
population who can _explain_ that is around 0.000000015%. We've enjoyed
the intricacies of flushVMmethodCache* for around 13 years, and I can't
claim to fully understand it. The only way to do that is read the VM
source code (oh, and get a PhD or greater experience in VMs, PICs etc.).
In an attempt to keep what's left of my sanity and productivity, I've
tried to avoid doing either.

I would suspect the cause is a bug, most probably introduced with all
the wonderful VM speed optimizations we've been enjoying. A simplistic
VM would probably behave like you imagined, and simply run the old
version; VW's VM is one of the most powerful out there, and far from
simplistic. "Normal" use of VW won't hit the problem, because both image
and VM are pretty aggressive about throwing away the whole VMmethodCache
on the slightest change.

Well, it seems that this is one of those shady areas. I will simply treat it as a feature of some magic black box... :-)
If nothing else, it reminded me "bad old days" when debugging a C program... :-)

Given what happens when you leave old stuff in the cache - as you have
seen - that's perhaps understandable. flushVMmethodCache tends to be
pretty expensive, though, so if you have an application that invokes
code that invokes the flush (e.g. recompiling a class), it can mount up.
Our database app was doing that several hundred times on each commit,
which became the major factor. We tried to set things up so it was
called only once at the end (we knew no methods from the classes in
question would be called in the interim). Oddly, this didn't work: the
image did the calls, but the cache for the classes in question was not
flushed. Eliot tried to explain this, but I think we didn't fully
understand each other - although I certainly learned a lot. In the end,
we rigged things so our classes didn't need to flush their cache at all,
made the updates to them by our own shortcut method that avoided the
flushVMmethodCache stuff, and everything went a lot faster and just
worked.

In my case, deployed application will do these nasty things once during its startup or maybe even better, all this stuff will be done during making of deploy image.

That experience was back in 3.0, and many things have changed in the
VMmethodCache since then. My suggestion would be two-fold:

1) create a minimal test case that exhibits the crash, and send it to
Cincom support

I tried it prior to write this response but found it is not that minimal (simple) so I canceled the effort.

2) if you only need this for tests, simply call flushVMmethodCache* at
appropriate places (as you have started doing). That's what you're meant
to be doing, and I can't see any way of avoiding it if you're really
changing the method dictionary.

HTH - and if it leads to an AR, I'd be grateful to be added to the
notification list, since problems in flushVMmethodCache* might bite us
too.

Steve

One way or the other, from now on I know that when messing with method dictionaries, I have to call #flushVMmethodCacheEntriesFor:.
Thank you for your answer,

Ladislav Lenart

On Tue, 28 Feb 2006 03:43:04 -0500, Ladislav Lenart
[hidden email]
wrote:

Hi,

just yesterday me and my colleague successfully solved 
a problem with seg-faulting VW7.3 image when running 
more test cases at once. All these tests were 
compiling methods, modifying method dictionaries (via
#at:put:) and then sending these new or modified methods.

The strange on this was, that when we ran only one test, 
never the imagecrashed (and the test was green). When 
we ran two tests, image crashed
often but not always. When we ran more of them, it 
crashed always. Because of this pattern of behavior, 
we thought that SUnitToo uses more
processes but this prooved wrong. Finally we took a look at
MethodWrappers and found that each wrapper immediately 
after its  install (or uninstall) calls method 
#flushVMmethodCacheEntriesFor:. We put call
to this method to one place (just after the #at:put:) 
and suddenly all works fine.

What I don't understand is the reason why the image crashed (in 
scavenging phase of GC). Method caches were not in sync with 
current state of image but I see no reason why the image should 
crash (I would expect different methods to be sent, but 
not this).

Could someone explain this to me in more detail please?

Ladislav Lenart

Re: Question about Behavior>>flushVMmethodCacheEntriesFor:

In reply to this post by Reinout Heeck

Reinout Heeck wrote:

Steven Kelly wrote:

1) create a minimal test case that exhibits the crash, and send it to
Cincom support


Pretty please.
This probably involves quite a bit of effort from your side but in the past we 
have enabled Eliot to flush out GC bugs that confounded him. A repeatable 
case provides the leverage to get it fixed.

'Pretty please' because we are currently suffering VM crashes in mmScavenge in 
one of our projects, the more datapoints others can offer us the more we are 
helped :-)


R
-

Well, when you please so pretty, reconsidered... :-)
I will try to write a complete but minimal test case that crashes the image (hopefully today). However the problem with this is, that (at least in my case) you need to call two tests simultanously (I mean select two test methods and press "Run"). Each of them separately simply works and never (well, never say never :-) crashes. We think that this is because GC is called between the tests...

Ladislav Lenart

Terry Raymond

RE: Question about Behavior>>flushVMmethodCacheEntriesFor:

In reply to this post by Ladislav Lenart

Ladislav

With respect to your issue of not logging particular
compile operations I ran into this problem with Objectivity.
I created the attached fileIn for VW 7. It might provide
what you need.

Terry

===========================================================
Terry Raymond Smalltalk Professional Debug Package
Crafted Smalltalk
80 Lazywood Ln.
Tiverton, RI 02878
(401) 624-4517 [hidden email]
<http://www.craftedsmalltalk.com>
===========================================================

> -----Original Message-----
> From: Ladislav Lenart [mailto:[hidden email]]
> Sent: Wednesday, March 01, 2006 4:05 AM
> To: Charles A. Monteiro
> Cc: vwnc
> Subject: Re: Question about Behavior>>flushVMmethodCacheEntriesFor:
>
> Charles A. Monteiro wrote:
>
> > yes, it depends on what he is doing. If creating classes and methods
> > at runtime one may not care. However, if you want to co-exist with
> > the VW IDE i.e. in dev mode you will certainly care. The following
> > are the dependents of ChangeSet in my image, note that because the
> > printStrings for some of these are quite involved I simplified by
> > just collecting the associated "instanceBehavior(s)"
>
> Well, I am doing all this in development image in unit tests, so I would
> like to coexist with browsers but in the same time I don't want these
> changes made in tests written to the ChangeSet...
>
> And what about my other question, there is really no one out there who
> can explain that to me? :-)
>
>
> Ladislav Lenart
>
> >
> > #(Parcel Override Refactory.Browser.RefactoryChangeManager
> > ChangeHistorian NamespaceChangeListener Store.XMainChangeSet
> > MiniChangeSetManager Refactory.Browser.PundleNavigatorPart
> > Refactory.Browser.ClassNavigatorPart
> > Refactory.Browser.MethodNavigatorPart
> > Refactory.Browser.BrowserCodeTool
> > Refactory.Browser.MethodNavigatorPart
> > Refactory.Browser.BrowserCodeTool
> > Refactory.Browser.SharedVariableProtocolNavigatorPart
> > Refactory.Browser.SharedVariableNavigatorPart
> > Refactory.Browser.MethodNavigatorPart Refactory.Browser.BrowserCodeTool)
> >
> > these all seem to be very much about the IDE. Having said that I think
> > I will check out what the NamespaceChangeListener does.
> >
> > -Charles
> > On Tue, 28 Feb 2006 13:07:13 -0500, Alan Knight <[hidden email]> wrote:
> >
> >> I wouldn't turn off notification, you're likely to confuse a bunch
> >> of other structures. Besides, it's relatively easy to compile
> >> without logging. For example, with Store loaded, see
> >> ClassDescription>>compileWithoutStoringSource:classified:. That's a
> >> shortcut used to improve Store source load times by compiling
> >> everything, then doing all of the logging at once. But in general,
> >> the part that compiles is separate from the part that logs. For
> >> another example, see
> >> ClassDescription>>compile:classified:notifying:attributes:environment:
> >> It should be pretty clear there which part is compiling and which
> >> part is logging.
> >>
> >> At 09:46 AM 2/28/2006, Charles A. Monteiro wrote:
> >>
> >>> Ladislav:
> >>>
> >>> The problem is that somewhere down the line from these you get calls
> to
> >>> ChangeSet. You can track this down and depending on what you want to
> do
> >>> you may be able to call something more specific. However, probably the
> >>> easiest thing may be to just tell the ChangeSet not to
> >>> "broadcastChanges"
> >>> i.e. there is a SharedVar that is by default set to true.
> >>>
> >>> The API provided is:
> >>>
> >>> ChangeSet ignoreChangesWhile: aBlock
> >>>
> >>> where in the block you are doing your dynamic behavior changes.
> >>>
> >>> hth,
> >>>
> >>> -Charles
> >>>
> >>>
> >>>> Finally I would like to know if there is a way (other methods for
> >>>> example?) how to prevent the following actions to be written to
> system
> >>>> changes:
> >>>> #addSelector:withMethod:category:
> >>>> #compile:classified:
> >>>> #removeSelector:
> >>>
> >>>
> >>>
> >>> On Tue, 28 Feb 2006 03:43:04 -0500, Ladislav Lenart
> >>> <[hidden email]>
> >>> wrote:
> >>>
> >>>> Hi,
> >>>>
> >>>> just yesterday me and my colleague successfully solved a problem with
> >>>> seg-faulting VW7.3 image when running more test cases at once. All
> >>>> these
> >>>> tests were compiling methods, modifying method dictionaries (via
> >>>> #at:put:) and then sending these new or modified methods.
> >>>>
> >>>> The strange on this was, that when we ran only one test, the image
> >>>> never
> >>>> crashed (and the test was green). When we ran two tests, image
> crashed
> >>>> often but not always. When we ran more of them, it crashed always.
> >>>> Because of this pattern of behavior, we thought that SUnitToo uses
> >>>> more
> >>>> processes but this prooved wrong. Finally we took a look at
> >>>> MethodWrappers and found that each wrapper immediately after its
> >>>> install
> >>>> (or uninstall) calls method #flushVMmethodCacheEntriesFor:. We put
> >>>> call
> >>>> to this method to one place (just after the #at:put:) and suddenly
> all
> >>>> works fine.
> >>>>
> >>>> What I don't understand is the reason why the image crashed (in
> >>>> scavenging phase of GC). Method caches were not in sync with current
> >>>> state of image but I see no reason why the image should crash (I
> would
> >>>> expect different methods to be sent, but not this).
> >>>>
> >>>> Could someone explain this to me in more detail please?
> >>>>
> >>>> Finally I would like to know if there is a way (other methods for
> >>>> example?) how to prevent the following actions to be written to
> system
> >>>> changes:
> >>>> #addSelector:withMethod:category:
> >>>> #compile:classified:
> >>>> #removeSelector:
> >>>>
> >>>> Thanks,
> >>>>
> >>>> Ladislav Lenart
> >>>
> >>>
> >>>
> >>>
> >>> --
> >>> Charles A. Monteiro
> >>
> >>
> >> --
> >> Alan Knight [|], Cincom Smalltalk Development
> >> [hidden email]
> >> [hidden email]
> >> http://www.cincom.com/smalltalk
> >>
> >> "The Static Typing Philosophy: Make it fast. Make it right. Make it
> >> run." - Niall Ross
> >
> >
> >
> >

NoLog.st (3K) Download Attachment

Charles A. Monteiro-2

Re: Question about Behavior>>flushVMmethodCacheEntriesFor:

In reply to this post by Ladislav Lenart

I also have sunits that do dynamic method compilation, I'll admit to being
lazy and not caring whether it scratched my package, so I will try this
out. My gut feeling is that much of this is to support RB trying to be
smart cache some things.

As far as to the other question i.e. why the image crashes if you don't
flush the method cache well , it seems like an Eliot question :)

-Charles

On Wed, 01 Mar 2006 04:04:58 -0500, Ladislav Lenart <[hidden email]>
wrote:

> Charles A. Monteiro wrote:
>
>> yes, it depends on what he is doing. If creating classes and methods
>> at runtime one may not care. However, if you want to co-exist with the
>> VW IDE i.e. in dev mode you will certainly care. The following are the
>> dependents of ChangeSet in my image, note that because the
>> printStrings for some of these are quite involved I simplified by just
>> collecting the associated "instanceBehavior(s)"
>
> Well, I am doing all this in development image in unit tests, so I would
> like to coexist with browsers but in the same time I don't want these
> changes made in tests written to the ChangeSet...
>
> And what about my other question, there is really no one out there who
> can explain that to me? :-)
>
>
> Ladislav Lenart
>
>>
>> #(Parcel Override Refactory.Browser.RefactoryChangeManager
>> ChangeHistorian NamespaceChangeListener Store.XMainChangeSet
>> MiniChangeSetManager Refactory.Browser.PundleNavigatorPart
>> Refactory.Browser.ClassNavigatorPart
>> Refactory.Browser.MethodNavigatorPart
>> Refactory.Browser.BrowserCodeTool
>> Refactory.Browser.MethodNavigatorPart
>> Refactory.Browser.BrowserCodeTool
>> Refactory.Browser.SharedVariableProtocolNavigatorPart
>> Refactory.Browser.SharedVariableNavigatorPart
>> Refactory.Browser.MethodNavigatorPart Refactory.Browser.BrowserCodeTool)
>>
>> these all seem to be very much about the IDE. Having said that I think
>> I will check out what the NamespaceChangeListener does.
>>
>> -Charles
>> On Tue, 28 Feb 2006 13:07:13 -0500, Alan Knight <[hidden email]> wrote:
>>
>>> I wouldn't turn off notification, you're likely to confuse a bunch of
>>> other structures. Besides, it's relatively easy to compile without
>>> logging. For example, with Store loaded, see
>>> ClassDescription>>compileWithoutStoringSource:classified:. That's a
>>> shortcut used to improve Store source load times by compiling
>>> everything, then doing all of the logging at once. But in general,
>>> the part that compiles is separate from the part that logs. For
>>> another example, see
>>> ClassDescription>>compile:classified:notifying:attributes:environment:
>>> It should be pretty clear there which part is compiling and which
>>> part is logging.
>>>
>>> At 09:46 AM 2/28/2006, Charles A. Monteiro wrote:
>>>
>>>> Ladislav:
>>>>
>>>> The problem is that somewhere down the line from these you get calls
>>>> to
>>>> ChangeSet. You can track this down and depending on what you want to
>>>> do
>>>> you may be able to call something more specific. However, probably the
>>>> easiest thing may be to just tell the ChangeSet not to
>>>> "broadcastChanges"
>>>> i.e. there is a SharedVar that is by default set to true.
>>>>
>>>> The API provided is:
>>>>
>>>> ChangeSet ignoreChangesWhile: aBlock
>>>>
>>>> where in the block you are doing your dynamic behavior changes.
>>>>
>>>> hth,
>>>>
>>>> -Charles
>>>>
>>>>
>>>>> Finally I would like to know if there is a way (other methods for
>>>>> example?) how to prevent the following actions to be written to
>>>>> system
>>>>> changes:
>>>>> #addSelector:withMethod:category:
>>>>> #compile:classified:
>>>>> #removeSelector:
>>>>
>>>>
>>>>
>>>> On Tue, 28 Feb 2006 03:43:04 -0500, Ladislav Lenart
>>>> <[hidden email]>
>>>> wrote:
>>>>
>>>>> Hi,
>>>>>
>>>>> just yesterday me and my colleague successfully solved a problem with
>>>>> seg-faulting VW7.3 image when running more test cases at once. All
>>>>> these
>>>>> tests were compiling methods, modifying method dictionaries (via
>>>>> #at:put:) and then sending these new or modified methods.
>>>>>
>>>>> The strange on this was, that when we ran only one test, the image
>>>>> never
>>>>> crashed (and the test was green). When we ran two tests, image
>>>>> crashed
>>>>> often but not always. When we ran more of them, it crashed always.
>>>>> Because of this pattern of behavior, we thought that SUnitToo uses
>>>>> more
>>>>> processes but this prooved wrong. Finally we took a look at
>>>>> MethodWrappers and found that each wrapper immediately after its
>>>>> install
>>>>> (or uninstall) calls method #flushVMmethodCacheEntriesFor:. We put
>>>>> call
>>>>> to this method to one place (just after the #at:put:) and suddenly
>>>>> all
>>>>> works fine.
>>>>>
>>>>> What I don't understand is the reason why the image crashed (in
>>>>> scavenging phase of GC). Method caches were not in sync with current
>>>>> state of image but I see no reason why the image should crash (I
>>>>> would
>>>>> expect different methods to be sent, but not this).
>>>>>
>>>>> Could someone explain this to me in more detail please?
>>>>>
>>>>> Finally I would like to know if there is a way (other methods for
>>>>> example?) how to prevent the following actions to be written to
>>>>> system
>>>>> changes:
>>>>> #addSelector:withMethod:category:
>>>>> #compile:classified:
>>>>> #removeSelector:
>>>>>
>>>>> Thanks,
>>>>>
>>>>> Ladislav Lenart
>>>>
>>>>
>>>>
>>>>
>>>> -- Charles A. Monteiro
>>>
>>>
>>> -- Alan Knight [|], Cincom Smalltalk Development
>>> [hidden email]
>>> [hidden email]
>>> http://www.cincom.com/smalltalk
>>>
>>> "The Static Typing Philosophy: Make it fast. Make it right. Make it
>>> run." - Niall Ross
>>
>>
>>
>>
>

--
Charles A. Monteiro

Charles A. Monteiro-2

Re: Question about Behavior>>flushVMmethodCacheEntriesFor:

In reply to this post by Ladislav Lenart

Ladislav:

I used the ChangeSet ignoreChangesWhile: block.

In the sunit in question I compile methods to the current class side of
the TestCase in question into a brand new protocol. Before using the api
below doing this would scratch i.e. mark dirty my package, it now does
not. So after I hit the sunit framework's "run" button and then toggle to
the class side I can cleary see what was just compiled. Now, what I have
not tested is whether if I have a browser already open on the class side
of my test case i.e. where the sunit compiles into whether the new method
will show up without me having to do a refresh or click on something etc.
For me that is just not a big deal if it does not.

As it stands I'm going to use "ChangeSet ignoreChangesWhile: block" for
these particular sunits that I have that do dynamic compilation. It still
seems like the least pain for what I am trying to accomplish.

Maybe you could try it out and let us know if you bump into any issues
with it. I will do the same.

-Charles

On Wed, 01 Mar 2006 04:04:58 -0500, Ladislav Lenart <[hidden email]>
wrote:

--
Charles A. Monteiro

Ladislav Lenart

Re: Question about Behavior>>flushVMmethodCacheEntriesFor:

Charles A. Monteiro wrote:

> Ladislav:
>
> I used the ChangeSet ignoreChangesWhile: block.
>
> In the sunit in question I compile methods to the current class side
> of the TestCase in question into a brand new protocol. Before using
> the api below doing this would scratch i.e. mark dirty my package, it
> now does not. So after I hit the sunit framework's "run" button and
> then toggle to the class side I can cleary see what was just
> compiled. Now, what I have not tested is whether if I have a browser
> already open on the class side of my test case i.e. where the sunit
> compiles into whether the new method will show up without me having
> to do a refresh or click on something etc. For me that is just not a
> big deal if it does not.
>
> As it stands I'm going to use "ChangeSet ignoreChangesWhile: block"
> for these particular sunits that I have that do dynamic compilation.
> It still seems like the least pain for what I am trying to accomplish.
>
> Maybe you could try it out and let us know if you bump into any
> issues with it. I will do the same.

This approach has only one potential illness (as far as I can see) and
that is when you have multiple processes running in your image. During
the time you run your tests (in one process), *all* changes (not only
those that were made by the tests) will be forgotten. But most of the
time this is not a problem...

Ladislav Lenart

>
> -Charles
>
> On Wed, 01 Mar 2006 04:04:58 -0500, Ladislav Lenart
> <[hidden email]> wrote:
>
>> Charles A. Monteiro wrote:
>>
>>> yes, it depends on what he is doing. If creating classes and
>>> methods at runtime one may not care. However, if you want to
>>> co-exist with the VW IDE i.e. in dev mode you will certainly care.
>>> The following are the dependents of ChangeSet in my image, note
>>> that because the printStrings for some of these are quite involved
>>> I simplified by just collecting the associated "instanceBehavior(s)"
>>
>>
>> Well, I am doing all this in development image in unit tests, so I
>> would like to coexist with browsers but in the same time I don't
>> want these changes made in tests written to the ChangeSet...
>>
>> And what about my other question, there is really no one out there
>> who can explain that to me? :-)
>>
>>
>> Ladislav Lenart
>>
>>>
>>> #(Parcel Override Refactory.Browser.RefactoryChangeManager
>>> ChangeHistorian NamespaceChangeListener Store.XMainChangeSet
>>> MiniChangeSetManager Refactory.Browser.PundleNavigatorPart
>>> Refactory.Browser.ClassNavigatorPart
>>> Refactory.Browser.MethodNavigatorPart
>>> Refactory.Browser.BrowserCodeTool
>>> Refactory.Browser.MethodNavigatorPart
>>> Refactory.Browser.BrowserCodeTool
>>> Refactory.Browser.SharedVariableProtocolNavigatorPart
>>> Refactory.Browser.SharedVariableNavigatorPart
>>> Refactory.Browser.MethodNavigatorPart
>>> Refactory.Browser.BrowserCodeTool)
>>>
>>> these all seem to be very much about the IDE. Having said that I
>>> think I will check out what the NamespaceChangeListener does.
>>>
>>> -Charles
>>> On Tue, 28 Feb 2006 13:07:13 -0500, Alan Knight <[hidden email]> wrote:
>>>
>>>> I wouldn't turn off notification, you're likely to confuse a bunch
>>>> of other structures. Besides, it's relatively easy to compile
>>>> without logging. For example, with Store loaded, see
>>>> ClassDescription>>compileWithoutStoringSource:classified:. That's
>>>> a shortcut used to improve Store source load times by compiling
>>>> everything, then doing all of the logging at once. But in general,
>>>> the part that compiles is separate from the part that logs. For
>>>> another example, see
>>>> ClassDescription>>compile:classified:notifying:attributes:environment:
>>>> It should be pretty clear there which part is compiling and which
>>>> part is logging.
>>>>
>>>> At 09:46 AM 2/28/2006, Charles A. Monteiro wrote:
>>>>
>>>>> Ladislav:
>>>>>
>>>>> The problem is that somewhere down the line from these you get
>>>>> calls to
>>>>> ChangeSet. You can track this down and depending on what you want
>>>>> to do
>>>>> you may be able to call something more specific. However, probably
>>>>> the
>>>>> easiest thing may be to just tell the ChangeSet not to
>>>>> "broadcastChanges"
>>>>> i.e. there is a SharedVar that is by default set to true.
>>>>>
>>>>> The API provided is:
>>>>>
>>>>> ChangeSet ignoreChangesWhile: aBlock
>>>>>
>>>>> where in the block you are doing your dynamic behavior changes.
>>>>>
>>>>> hth,
>>>>>
>>>>> -Charles
>>>>>
>>>>>
>>>>>> Finally I would like to know if there is a way (other methods for
>>>>>> example?) how to prevent the following actions to be written to
>>>>>> system
>>>>>> changes:
>>>>>> #addSelector:withMethod:category:
>>>>>> #compile:classified:
>>>>>> #removeSelector:
>>>>>
>>>>>
>>>>>
>>>>>
>>>>> On Tue, 28 Feb 2006 03:43:04 -0500, Ladislav Lenart
>>>>> <[hidden email]>
>>>>> wrote:
>>>>>
>>>>>> Hi,
>>>>>>
>>>>>> just yesterday me and my colleague successfully solved a problem
>>>>>> with
>>>>>> seg-faulting VW7.3 image when running more test cases at once.
>>>>>> All these
>>>>>> tests were compiling methods, modifying method dictionaries (via
>>>>>> #at:put:) and then sending these new or modified methods.
>>>>>>
>>>>>> The strange on this was, that when we ran only one test, the
>>>>>> image never
>>>>>> crashed (and the test was green). When we ran two tests, image
>>>>>> crashed
>>>>>> often but not always. When we ran more of them, it crashed always.
>>>>>> Because of this pattern of behavior, we thought that SUnitToo
>>>>>> uses more
>>>>>> processes but this prooved wrong. Finally we took a look at
>>>>>> MethodWrappers and found that each wrapper immediately after
>>>>>> its install
>>>>>> (or uninstall) calls method #flushVMmethodCacheEntriesFor:. We
>>>>>> put call
>>>>>> to this method to one place (just after the #at:put:) and
>>>>>> suddenly all
>>>>>> works fine.
>>>>>>
>>>>>> What I don't understand is the reason why the image crashed (in
>>>>>> scavenging phase of GC). Method caches were not in sync with current
>>>>>> state of image but I see no reason why the image should crash (I
>>>>>> would
>>>>>> expect different methods to be sent, but not this).
>>>>>>
>>>>>> Could someone explain this to me in more detail please?
>>>>>>
>>>>>> Finally I would like to know if there is a way (other methods for
>>>>>> example?) how to prevent the following actions to be written to
>>>>>> system
>>>>>> changes:
>>>>>> #addSelector:withMethod:category:
>>>>>> #compile:classified:
>>>>>> #removeSelector:
>>>>>>
>>>>>> Thanks,
>>>>>>
>>>>>> Ladislav Lenart
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>> -- Charles A. Monteiro
>>>>
>>>>
>>>>
>>>> -- Alan Knight [|], Cincom Smalltalk Development
>>>> [hidden email]
>>>> [hidden email]
>>>> http://www.cincom.com/smalltalk
>>>>
>>>> "The Static Typing Philosophy: Make it fast. Make it right. Make
>>>> it run." - Niall Ross
>>>
>>>
>>>
>>>
>>>
>>
>
>
>

Alan Knight-2

Re: Question about Behavior>>flushVMmethodCacheEntriesFor:

>This approach has only one potential illness (as far as I can see) and that is when you have multiple processes running in your image. During the time you run your tests (in one process), *all* changes (not only those that were made by the tests) will be forgotten. But most of the time this is not a problem...

I vaguely recall that management of code in packages happens as a result of these notifications as well, so if you're concerned about this code going into particular packages, that might also be a problem.

--
Alan Knight [|], Cincom Smalltalk Development
[hidden email]
[hidden email]
http://www.cincom.com/smalltalk

"The Static Typing Philosophy: Make it fast. Make it right. Make it run." - Niall Ross

Charles A. Monteiro-2

Re: Question about Behavior>>flushVMmethodCacheEntriesFor:

absolutely - this will prevent packages from being dirtied, which is why
when I worked on integrating VW Traits to StORE it was not as simple as
using the ignore block api. What I understood in this case from Ladislav,
was that he had some dynamic compilation of which he was testing in sunits
and he wanted to prevent the usual side effects.

Of course, Ladislav is right about trying to code normally while this
ignore block is doing its thing. I personally only do quick sunit tests in
my working dev image so it is not a problem. Running entire comprehensive
suites of sunits is done in a dedicated untouched latest build dev image.
So for example if running Pollocks 50,000 ++ sunits, that definitely runs
in its separate image. As a matter of fact, often on its own box and once
in a while in its own dedicated office :)

-Charles

On Wed, 01 Mar 2006 17:49:12 -0500, Alan Knight <[hidden email]> wrote:

>
>> This approach has only one potential illness (as far as I can see) and
>> that is when you have multiple processes running in your image. During
>> the time you run your tests (in one process), *all* changes (not only
>> those that were made by the tests) will be forgotten. But most of the
>> time this is not a problem...
>
> I vaguely recall that management of code in packages happens as a result
> of these notifications as well, so if you're concerned about this code
> going into particular packages, that might also be a problem.
>
>
> --
> Alan Knight [|], Cincom Smalltalk Development
> [hidden email]
> [hidden email]
> http://www.cincom.com/smalltalk
>
> "The Static Typing Philosophy: Make it fast. Make it right. Make it
> run." - Niall Ross

--
Charles A. Monteiro

Ladislav Lenart

SPAM Re: Question about Behavior>>flushVMmethodCacheEntriesFor: - minimal TestCase

In reply to this post by Ladislav Lenart

Hi,

I've finally wrote the minimal reproducable test case, that leads to VW
segfault (see the attachment).
However I am not a member of any other VW related conference, so I
please some one to push it forward to Cincom (Reinout?).

Thanks,

Ladislav Lenart

<?xml version="1.0"?>

<st-source>
<time-stamp>From VisualWorksÂ®, 7.3 of 3. prosinec 2004 on 3. bÅezen 2006 at 11:48:25</time-stamp>


<component-property>
<name>VWSegfaultTest</name> <type>package</type>
<property>fractalCreator</property> <value>'fractal'</value>
</component-property>

<component-property>
<name>VWSegfaultTest</name> <type>package</type>
<property>prerequisiteParcels</property> <value>#(#('SUnitToo' ''))</value>
</component-property>

<component-property>
<name>VWSegfaultTest</name> <type>package</type>
<property>developmentPrerequisites</property> <value>#(#(#any 'SUnitToo' ''))</value>
</component-property>

<component-property>
<name>VWSegfaultTest</name> <type>package</type>
<property>comment</property> <value>'VWSegfaultTest

I contains minimal reproducable test case (VWSegfaultTest) that leads to VW segfault.
This is achieved by playing with method dictionaries, compiling methods and calling them in turn.
'</value>
</component-property>

<class>
<name>VWSegfaultTest</name>
<environment>SUnit</environment>
<super>SUnit.TestCase</super>
<private>false</private>
<indexed-type>none</indexed-type>
<inst-vars>dummy </inst-vars>
<class-inst-vars></class-inst-vars>
<imports></imports>
<category></category>
<attributes>
<package>VWSegfaultTest</package>
</attributes>
</class>

<comment>
<class-id>SUnit.VWSegfaultTest</class-id>
<body>VWSegfaultTest

Hi,

I am the minimal reproducable TestCase that leads to VW segfault.

As I said, my only purpose is to seg-fault VW I am running in and I am pretty good at it, though the process itself is nondeterministic, because you actually have to run me more than once in order to get the "desired" results.

I achieve this particular behavior by playing with my method dictionary and compiling methods that I then call in turn. When call to #flushVMmethodCacheEntriesFor: is omitted, the seg-fault is ready to happen (see VWSegfaultTest>>methodDictionaryAt:put:).

I was written by Ladislav Lenart ([hidden email]) on March 2006.
I was successfully tested on [vw7.3]Linux/Debian][Intel Pentium IV machine].

Use me with caution!

Instance Variables:
dummy <String>
</body>
</comment>

<methods>
<class-id>SUnit.VWSegfaultTest</class-id> <category>initialize-release</category>

<body package="VWSegfaultTest" selector="dummy:">dummy: aString

dummy := aString.</body>
</methods>

<methods>
<class-id>SUnit.VWSegfaultTest</class-id> <category>private-method dict</category>

<body package="VWSegfaultTest" selector="methodDictionaryAt:put:">methodDictionaryAt: selectorSymbol put: aCompiledMethod

self class methodDictionary at: selectorSymbol put: aCompiledMethod.

"Uncomment the following to prevent the VW seg-fault:"
"self class flushVMmethodCacheEntriesFor: selectorSymbol."</body>

<body package="VWSegfaultTest" selector="methodDictionaryAt:">methodDictionaryAt: selectorSymbol

^self class methodDictionary at: selectorSymbol.</body>
</methods>

<methods>
<class-id>SUnit.VWSegfaultTest</class-id> <category>private-accessing</category>

<body package="VWSegfaultTest" selector="createSubstituteMethodSource">createSubstituteMethodSource

^
'dummy: aString

"Auto-generated method - do not modify!"

^self primitive_dummy: (self convert_dummy: aString).'.</body>
</methods>

<methods>
<class-id>SUnit.VWSegfaultTest</class-id> <category>generate-support</category>

<body package="VWSegfaultTest" selector="convert_dummy:">convert_dummy: aString

^aString asText.</body>
</methods>

<methods>
<class-id>SUnit.VWSegfaultTest</class-id> <category>actions</category>

<body package="VWSegfaultTest" selector="doTheTrick">doTheTrick

self backupMethod.
self compileSubstituteMethod.
self callSubstituteMethod.
self restoreMethod.</body>
</methods>

<methods>
<class-id>SUnit.VWSegfaultTest</class-id> <category>private</category>

<body package="VWSegfaultTest" selector="callSubstituteMethod">callSubstituteMethod

self dummy: 'new value'.
self assert: (dummy = 'new value' asText).</body>

<body package="VWSegfaultTest" selector="compileSubstituteMethod">compileSubstituteMethod

self class
compile: self createSubstituteMethodSource
classified: 'initialize-release'.</body>

<body package="VWSegfaultTest" selector="backupMethod">backupMethod

| method |
method := self methodDictionaryAt: #dummy:.
self methodDictionaryAt: #primitive_dummy: put: method.</body>

<body package="VWSegfaultTest" selector="restoreMethod">restoreMethod

| method |
method := self methodDictionaryAt: #primitive_dummy:.
self methodDictionaryAt: #dummy: put: method.
self class removeSelector: #primitive_dummy:.</body>
</methods>

<methods>
<class-id>SUnit.VWSegfaultTest</class-id> <category>tests</category>

<body package="VWSegfaultTest" selector="test_secondMethod">test_secondMethod

self doTheTrick.</body>

<body package="VWSegfaultTest" selector="test_thirdMethod">test_thirdMethod

self doTheTrick.</body>

<body package="VWSegfaultTest" selector="test_firstMethod">test_firstMethod

self doTheTrick.</body>
</methods>

</st-source>

Reinout Heeck

[BUG] #flushVMmethodCacheEntriesFor: - minimal TestCase

Ladislav Lenart wrote:
> I've finally wrote the minimal reproducable test case, that leads to VW
> segfault (see the attachment).
> However I am not a member of any other VW related conference, so I
> please some one to push it forward to Cincom (Reinout?).

No need, you should be plenty visible here and thus can stay part of the
discussion.

I did find your choice of the subject a bit awkward though :-)

R
-

Ladislav Lenart

Re: [BUG] #flushVMmethodCacheEntriesFor: - minimal TestCase

Reinout Heeck wrote:

Ladislav Lenart wrote:

I've finally wrote the minimal reproducable test case, that leads to VW
segfault (see the attachment).
However I am not a member of any other VW related conference, so I
please some one to push it forward to Cincom (Reinout?).


No need, you should be plenty visible here and thus can stay part of the 
discussion.

I did find your choice of the subject a bit awkward though :-)

Well, me too. The mail was considered a spam somewhere on the road (maybe because of plain XML in attachment).
One way or the other, the test made it at least to some of you...

Sorry for inconvenience,

Ladislav Lenart

Terry Raymond

RE: SPAM Re: Question about Behavior>>flushVMmethodCacheEntriesFor: - minimal TestCase

In reply to this post by Ladislav Lenart

Ladislav

I am a little confused as to the point you are trying to
make.

Your filein states

I achieve this particular behavior by playing with my method dictionary and
compiling methods that I then call in turn. When call to
#flushVMmethodCacheEntriesFor: is omitted, the seg-fault is ready to happen
(see VWSegfaultTest>>methodDictionaryAt:put:).

I don't see your point. It is a system requirement that
if you change a compiled method you MUST flush the cache.

Why do you insist on not flushing the cache?

Terry

===========================================================
Terry Raymond Smalltalk Professional Debug Package
Crafted Smalltalk
80 Lazywood Ln.
Tiverton, RI 02878
(401) 624-4517 [hidden email]
<http://www.craftedsmalltalk.com>
===========================================================

> -----Original Message-----
> From: Ladislav Lenart [mailto:[hidden email]]
> Sent: Friday, March 03, 2006 5:50 AM
> To: vwnc
> Subject: **SPAM** Re: Question about
> Behavior>>flushVMmethodCacheEntriesFor: - minimal TestCase
>
> Hi,
>
> I've finally wrote the minimal reproducable test case, that leads to VW
> segfault (see the attachment).
> However I am not a member of any other VW related conference, so I
> please some one to push it forward to Cincom (Reinout?).
>
> Thanks,
>
> Ladislav Lenart

Ladislav Lenart

Re: SPAM Re: Question about Behavior>>flushVMmethodCacheEntriesFor: - minimal TestCase

Terry Raymond wrote:

Ladislav

I am a little confused as to the point you are trying to
make.

Your filein states

I achieve this particular behavior by playing with my method dictionary and
compiling methods that I then call in turn. When call to
#flushVMmethodCacheEntriesFor: is omitted, the seg-fault is ready to happen
(see VWSegfaultTest>>methodDictionaryAt:put:).

I don't see your point. It is a system requirement that
if you change a compiled method you MUST flush the cache.

Why do you insist on not flushing the cache?

Well, I do not insist on it. I was just unaware of it until now. I posted the problem along with "the solution" and was ask to create a minimal reproducable test case that could potentially help VM developpers.

And so I did it (sorry for that... :-)

However the strange thing about it is: "Why the VM segfaults at all?"
I would understand wrong methods to be called, but I don't understand this behavior and I am pretty sure that I am not alone...

Ladislav Lenart

Terry
 
===========================================================
Terry Raymond       Smalltalk Professional Debug Package
Crafted Smalltalk
80 Lazywood Ln.
Tiverton, RI  02878
(401) 624-4517      [hidden email]
<http://www.craftedsmalltalk.com>
===========================================================

-----Original Message-----
From: Ladislav Lenart [[hidden email]]
Sent: Friday, March 03, 2006 5:50 AM
To: vwnc
Subject: **SPAM** Re: Question about
Behavior>>flushVMmethodCacheEntriesFor: - minimal TestCase

Hi,

I've finally wrote the minimal reproducable test case, that leads to VW
segfault (see the attachment).
However I am not a member of any other VW related conference, so I
please some one to push it forward to Cincom (Reinout?).

Thanks,

Ladislav Lenart

Question about Behavior>>flushVMmethodCacheEntriesFor:

Question about Behavior>>flushVMmethodCacheEntriesFor:

Re: Question about Behavior>>flushVMmethodCacheEntriesFor:

Re: Question about Behavior>>flushVMmethodCacheEntriesFor:

Re: Question about Behavior>>flushVMmethodCacheEntriesFor:

Re: Question about Behavior>>flushVMmethodCacheEntriesFor:

RE: Question about Behavior>>flushVMmethodCacheEntriesFor:

Re: Question about Behavior>>flushVMmethodCacheEntriesFor:

Re: Question about Behavior>>flushVMmethodCacheEntriesFor:

Re: Question about Behavior>>flushVMmethodCacheEntriesFor:

RE: Question about Behavior>>flushVMmethodCacheEntriesFor:

Re: Question about Behavior>>flushVMmethodCacheEntriesFor:

Re: Question about Behavior>>flushVMmethodCacheEntriesFor:

Re: Question about Behavior>>flushVMmethodCacheEntriesFor:

Re: Question about Behavior>>flushVMmethodCacheEntriesFor:

Re: Question about Behavior>>flushVMmethodCacheEntriesFor:

**SPAM** Re: Question about Behavior>>flushVMmethodCacheEntriesFor: - minimal TestCase

[BUG] #flushVMmethodCacheEntriesFor: - minimal TestCase

Re: [BUG] #flushVMmethodCacheEntriesFor: - minimal TestCase

RE: **SPAM** Re: Question about Behavior>>flushVMmethodCacheEntriesFor: - minimal TestCase

Re: **SPAM** Re: Question about Behavior>>flushVMmethodCacheEntriesFor: - minimal TestCase

SPAM Re: Question about Behavior>>flushVMmethodCacheEntriesFor: - minimal TestCase

RE: SPAM Re: Question about Behavior>>flushVMmethodCacheEntriesFor: - minimal TestCase

Re: SPAM Re: Question about Behavior>>flushVMmethodCacheEntriesFor: - minimal TestCase