[vwnc] Inspecting thisContext on VW7.6

IIRC, the resolution was that this was a bug of the inspector due to accessing a context object that was not fully reified for use by the image.  It has been addressed since then, and the fix is included in 7.7.

 

Andres.

---

From: [hidden email] [mailto:[hidden email]] On Behalf Of Vacha Petr
Sent: Monday, December 29, 2008 6:44 AM
To: [hidden email]
Subject: [vwnc] Inspecting thisContext on VW7.6

Hi all,

has somebody found why the image crashes when inspecting thisContext using "thisContext inspect."? I found a thread about this in archive (05/2008), but no resolution of it (asking just for interest, does not make any complication to me). I'm running Windows XPSP3 and seeing reported behavior (Inspect through menu works ok, "thisContext inspect." -> DoIt crashes image, "thisContext inspect." -> DebugIt with stepping works also correctly (Inspector gets shown correctly).

 

Greets,

Petr Vacha

_______________________________________________
vwnc mailing list
[hidden email]
http://lists.cs.uiuc.edu/mailman/listinfo/vwnc

IIRC, the resolution was that this was a bug of the inspector due to accessing a context object that was not fully reified for use by the image.  It has been addressed since then, and the fix is included in 7.7.

 

Andres.

---

From: [hidden email] [mailto:[hidden email]] On Behalf Of Vacha Petr
Sent: Monday, December 29, 2008 6:44 AM
To: [hidden email]
Subject: [vwnc] Inspecting thisContext on VW7.6

Hi all,

has somebody found why the image crashes when inspecting thisContext using "thisContext inspect."? I found a thread about this in archive (05/2008), but no resolution of it (asking just for interest, does not make any complication to me). I'm running Windows XPSP3 and seeing reported behavior (Inspect through menu works ok, "thisContext inspect." -> DoIt crashes image, "thisContext inspect." -> DebugIt with stepping works also correctly (Inspector gets shown correctly).

 

Greets,

Petr Vacha

_______________________________________________
vwnc mailing list
[hidden email]
http://lists.cs.uiuc.edu/mailman/listinfo/vwnc

Your model didn't apply to primitives 62 and 73, in the interests of speed. The inspector was calling those. It's been changed to call 162/173 instead, which are slow but safe.

Terry, the AR is 54113. For those with support, there is a list of resolutions that goes out periodically, and I believe the resolutions are all available via http://supportweb.cincom.com

At 02:17 AM 12/31/2008, Eliot Miranda wrote:

On Mon, Dec 29, 2008 at 8:09 AM, Valloud, Andres <[hidden email]> wrote:

IIRC, the resolution was that this was a bug of the inspector due to accessing a context object that was not fully reified for use by the image.  It has been addressed since then, and the fix is included in 7.7.

 

Andres.

How's that?  My model of the context reification scheme (know it? I wrote it!) is that its the VM's responsibility to make sure contexts are created for frames on demand, and to ensure that any accesses to contexts that are proxies for frames are handled correctly (forwarded to the frame, or cause the frame to be flushed and the context made fully heap-resident).  It was not at all my intention that one should have to be careful inspecting contexts. There are limits (don't store something bogus into method, sender, stack pointer and pc fields, etc) but at least reads are supposed to be open season.

What gives?

---

From: [hidden email] [[hidden email]] On Behalf Of Vacha Petr

Sent: Monday, December 29, 2008 6:44 AM

To: [hidden email]

Subject: [vwnc] Inspecting thisContext on VW7.6

Hi all,

has somebody found why the image crashes when inspecting thisContext using "thisContext inspect."? I found a thread about this in archive (05/2008), but no resolution of it (asking just for interest, does not make any complication to me). I'm running Windows XPSP3 and seeing reported behavior (Inspect through menu works ok, "thisContext inspect." -> DoIt crashes image, "thisContext inspect." -> DebugIt with stepping works also correctly (Inspector gets shown correctly).

 

Greets,

Petr Vacha

_______________________________________________

vwnc mailing list

[hidden email]

http://lists.cs.uiuc.edu/mailman/listinfo/vwnc

_______________________________________________
vwnc mailing list
[hidden email]
http://lists.cs.uiuc.edu/mailman/listinfo/vwnc

--

Alan Knight [|], Engineering Manager, Cincom Smalltalk

[hidden email]

[hidden email]

http://www.cincom.com/smalltalk

It's not doing a message send, but rather evaluating a method directly against the object. So the VM's assumption is perhaps more accurately stated that the image will not cause primitive 62 or 73 to be executed against contexts in a state where they don't work.

As far as using the mirror primitives, how is that different from what it's doing now ("changed to call 162/173 instead")?.

At 12:00 PM 12/31/2008, Eliot Miranda wrote:

Hi Alan,

On Wed, Dec 31, 2008 at 7:26 AM, Alan Knight <[hidden email]> wrote:

Your model didn't apply to primitives 62 and 73, in the interests of speed. The inspector was calling those. It's been changed to call 162/173 instead, which are slow but safe.

Apologies for being a stickler but I don't think that's entirely right..  62 is primitive size and 73 is primitive instVarAt.  Primitive 802 is contextSize and primitive 803 is primitiveContextInstVarAt:.  So the VM's assumption is that the image will arrange that Context overrides all methods that have primitives 62 & 73 with the Context versions.  This preserves the sanctity of contexts and allows 62 and 73 to operate at full speed.

In fact the full range of context accessing primitives are

       527: contextLocalAt
       528: contextLocalAtPut
       800: contextAt
       801: contextAtPut
       802: contextSize
       803: contextInstVarAt
       804: contextInstVarAtPut

So there is some mistake in failing to arrange that Context overrides methods with primitives 62 & 73 _or_ there is a super call somewhere, which ould put a spanner in the works that my approach can't solve.

But it does seem plausible that the right fix is for the inspector to use the mirror primitives:
        160: mirrorAt
        161: mirrorAtPut
        162: mirrorSize
        172: mirrorBecome
        173: mirrorInstVarAt
        174: mirrorInstVarAtPut
        175: mirrorHash
        176: mirrorGetImmutability
        177: mirrorSetImmutability
        209: mirrorNotEquivalent
        210: mirrorEquivalent
        211: mirrorClass

These take as an extra argument the object whose state is to be accessed and hence allow the execution simulation machinery (e.g. debugger) and inspectors to reach inside objects, avoiding sending messages to objects when what is wanted is to access their state.  e.g. when the debugger tries to lookup a message it shouldn't end up sending class to a proxy that forwards the message to some remote receiver.  Instead it should access the actual class of the proxy and lookup the message in the proxy.

Terry, the AR is 54113. For those with support, there is a list of resolutions that goes out periodically, and I believe the resolutions are all available via http://supportweb.cincom.com

At 02:17 AM 12/31/2008, Eliot Miranda wrote:

On Mon, Dec 29, 2008 at 8:09 AM, Valloud, Andres <[hidden email]> wrote:

IIRC, the resolution was that this was a bug of the inspector due to accessing a context object that was not fully reified for use by the image.  It has been addressed since then, and the fix is included in 7.7.

 

Andres.

How's that?  My model of the context reification scheme (know it? I wrote it!) is that its the VM's responsibility to make sure contexts are created for frames on demand, and to ensure that any accesses to contexts that are proxies for frames are handled correctly (forwarded to the frame, or cause the frame to be flushed and the context made fully heap-resident).  It was not at all my intention that one should have to be careful inspecting contexts. There are limits (don't store something bogus into method, sender, stack pointer and pc fields, etc) but at least reads are supposed to be open season.

What gives?

---

From: [hidden email] [[hidden email][hidden email]] On Behalf Of Vacha Petr

Sent: Monday, December 29, 2008 6:44 AM

To: [hidden email]

Subject: [vwnc] Inspecting thisContext on VW7.6

Hi all,

has somebody found why the image crashes when inspecting thisContext using "thisContext inspect."? I found a thread about this in archive (05/2008), but no resolution of it (asking just for interest, does not make any complication to me). I'm running Windows XPSP3 and seeing reported behavior (Inspect through menu works ok, "thisContext inspect." -> DoIt crashes image, "thisContext inspect." -> DebugIt with stepping works also correctly (Inspector gets shown correctly).

 

Greets,

Petr Vacha

_______________________________________________

vwnc mailing list

[hidden email]

http://lists.cs.uiuc.edu/mailman/listinfo/vwnc

_______________________________________________

vwnc mailing list

[hidden email]

http://lists.cs.uiuc.edu/mailman/listinfo/vwnc

--

Alan Knight [|], Engineering Manager, Cincom Smalltalk

[hidden email]

[hidden email]

http://www.cincom.com/smalltalk

_______________________________________________
vwnc mailing list
[hidden email]
http://lists.cs.uiuc.edu/mailman/listinfo/vwnc

--

Alan Knight [|], Engineering Manager, Cincom Smalltalk

[hidden email]

[hidden email]

http://www.cincom.com/smalltalk