Smalltalk › Cincom › VisualWorks

Question about Behavior>>flushVMmethodCacheEntriesFor:

_‹ Previous Topic Next Topic _›

Classic

List

Threaded

22 messages Options

Terry Raymond

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

Ladislav

I don’t know why it seg faults, but I enountered it a few years ago

as part of developing the pdp debugger. When you put a probe

into a method in the debugger, the debugger would also change the

compiled method for current context so it would not have to be

restarted. For a while we had problems with flushing the method cache.

You should also be aware that there are a few methods for flushing

the method cache. I’m not sure what the conditions are for selecting

which method to use.

Terry

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

From: Ladislav Lenart [mailto:[hidden email]]
Sent: Friday, March 03, 2006 8:02 AM
To: Terry Raymond
Cc: 'vwnc'
Subject: 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

Charles A. Monteiro-2

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

In reply to this post by Ladislav Lenart

I wonder what is worse the wrong method being called or the image crapping
out. We should not allow for the wrong method to be called but perhaps
just blowing up is too rude. What would be a good way of handling this?

-Charles

On Fri, 03 Mar 2006 08:01:30 -0500, Ladislav Lenart <[hidden email]>
wrote:

> 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 [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
>
>
>
>
>
>

--
Charles A. Monteiro

Question about Behavior>>flushVMmethodCacheEntriesFor:

RE: **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

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