Smalltalk › Squeak › Squeak - Dev

Re: Why "context top" points to "tempVector" and not to variable value?

_‹ Previous Topic Next Topic _›

Classic

List

Threaded

8 messages Options

Bert Freudenberg

Re: Why "context top" points to "tempVector" and not to variable value?

[moving to squeak-dev since this does not appear to be a VM problem]

I’d say it’s not only confusing, but actually wrong, since at that point the stack is empty. The context’s stackPtr is 1, equal to the method’s numTemps, so there is no valid stack top.

Another confusing thing is that when you put these lines into a method and step into it, #(nil nil) will be on the stack. That’s because the context’s pc is 27, it just pushed the temp vector, but has not stored it yet:

25 <8A 02> push: (Array new: 2)

27 <68> popIntoTemp: 0

28 <10> pushTemp: 0

29 <8F 10 00 09> closureNumCopied: 1 numArgs: 0 bytes 33 to 41

33 <20> pushConstant: 'test'

34 <8E 00 00> popIntoTemp: 0 inVectorAt: 0

37 <21> pushConstant: 'test2'

38 <8D 01 00> storeIntoTemp: 1 inVectorAt: 0

41 <7D> blockReturn

42 <C9> send: value

43 <87> pop

44 <8C 01 00> pushTemp: 1 inVectorAt: 0

47 <D2> send: halt

48 <7C> returnTop

Really the context should have been stepped over the temp vector initialization code … The way it is now, there is no “selection” at all, the first “step” in the debugger appears to do nothing.

- Bert -

On 11.05.2016, at 12:02, Denis Kudriashov <[hidden email]> wrote:

I found reason about it.
When message send executed it pops receiver from current stack.

But anyway it is very confusing to not see receiver as stack top in debugger. Maybe extra field "current receiver" should be added to debugger in that case

2016-05-11 11:51 GMT+02:00 Denis Kudriashov <[hidden email]>:
Here better example to see problem:

| t d |
[ t := 'test'.
d := 'test2' ] value.
t.
^ d halt

Stack top here will show #('test' test2') which is completely confusing

2016-05-11 11:45 GMT+02:00 Denis Kudriashov <[hidden email]>:
Hi.

Try to debug following script:

| t |
[ t := 'test' ] value.
^ t halt

You will see in debugger #('test') as stack top value. Why it is not 'test'?
I understand that hidden arrays used for variables which are used in closures. But why "context top" in that cases points to vector instead of variable value?

Best regards,
Denis

smime.p7s (5K) Download Attachment

Denis Kudriashov

Re: Why "context top" points to "tempVector" and not to variable value?

And here example with not empty stack but still confusing:

| t |
[ t := 'test'] value.

2016-05-11 15:26 GMT+02:00 Bert Freudenberg <[hidden email]>:

[moving to squeak-dev since this does not appear to be a VM problem]

I’d say it’s not only confusing, but actually wrong, since at that point the stack is empty. The context’s stackPtr is 1, equal to the method’s numTemps, so there is no valid stack top.

Another confusing thing is that when you put these lines into a method and step into it, #(nil nil) will be on the stack. That’s because the context’s pc is 27, it just pushed the temp vector, but has not stored it yet:

25 <8A 02> push: (Array new: 2)
27 <68> popIntoTemp: 0
28 <10> pushTemp: 0
29 <8F 10 00 09> closureNumCopied: 1 numArgs: 0 bytes 33 to 41
33 <20> pushConstant: 'test'
34 <8E 00 00> popIntoTemp: 0 inVectorAt: 0
37 <21> pushConstant: 'test2'
38 <8D 01 00> storeIntoTemp: 1 inVectorAt: 0
41 <7D> blockReturn
42 <C9> send: value
43 <87> pop
44 <8C 01 00> pushTemp: 1 inVectorAt: 0
47 <D2> send: halt
48 <7C> returnTop

Really the context should have been stepped over the temp vector initialization code … The way it is now, there is no “selection” at all, the first “step” in the debugger appears to do nothing.

- Bert -

On 11.05.2016, at 12:02, Denis Kudriashov <[hidden email]> wrote:

I found reason about it.
When message send executed it pops receiver from current stack.

But anyway it is very confusing to not see receiver as stack top in debugger. Maybe extra field "current receiver" should be added to debugger in that case

2016-05-11 11:51 GMT+02:00 Denis Kudriashov <[hidden email]>:
Here better example to see problem:

| t d |
[ t := 'test'.
d := 'test2' ] value.
t.
^ d halt

Stack top here will show #('test' test2') which is completely confusing

2016-05-11 11:45 GMT+02:00 Denis Kudriashov <[hidden email]>:
Hi.

Try to debug following script:

| t |
[ t := 'test' ] value.
^ t halt

You will see in debugger #('test') as stack top value. Why it is not 'test'?
I understand that hidden arrays used for variables which are used in closures. But why "context top" in that cases points to vector instead of variable value?

Best regards,
Denis

Bert Freudenberg

Re: Why "context top" points to "tempVector" and not to variable value?

On 11.05.2016, at 15:40, Denis Kudriashov <[hidden email]> wrote:

And here example with not empty stack but still confusing:
| t |
[ t := 'test'] value.

I think I just fixed both problems in trunk. Update and try again?

- Bert -

smime.p7s (5K) Download Attachment

Chris Muller-3

Re: Why "context top" points to "tempVector" and not to variable value?

Great discussion, the debugger is the most powerful browser.
Unfortunately, we still have this very painful and highly occurring
bug that renders debugging "Through" essentially too dangerous to use
at all..

For example:

SearchTopic new updateContents

Shift+Cmd+D to "Debug it", then press Through Through (i.e., step
through "updateContents").

... you now have an inescapable Emergency Evaluator.

This is a new bug, right?

I have a lot of code that uses Mutexes, so I pretty much cannot risk
debugging Through at all anymore. :(

On Wed, May 11, 2016 at 8:44 AM, Bert Freudenberg <[hidden email]> wrote:

> On 11.05.2016, at 15:40, Denis Kudriashov <[hidden email]> wrote:
>
>
> And here example with not empty stack but still confusing:
>
> | t |
> [ t := 'test'] value.
>
>
> I think I just fixed both problems in trunk. Update and try again?
>
> - Bert -
>
>
>
>

marcel.taeumel

Re: Why "context top" points to "tempVector" and not to variable value?

Hi Chris,

this might be new. There is a DNU on the receiver, which is the mutex, in ContextPart >> #doPrimitive:method:receiver:args:.

So, we do not have (and did not have in 5.0) any implementors of #primitiveEnterCriticalSectionOnBehalfOf: or #primitiveTestAndSetOwnershipOfCriticalSectionOnBehalfOf:.

Is there some code missing? Or is this VM magic?

Best,
Marcel

marcel.taeumel

Re: Why "context top" points to "tempVector" and not to variable value?

Hi, there.

There seems to be a bug with "through" and Mutex. Try to debug-it via "through":

Mutex new critical: [3+4].

It works fine with a Semaphore:

Semaphore forMutualExclusion critical: [3+4].

Best,
Marcel

Denis Kudriashov

Re: Why "context top" points to "tempVector" and not to variable value?

In reply to this post by marcel.taeumel

2016-05-12 9:12 GMT+02:00 marcel.taeumel <[hidden email]>:

So, we do not have (and did not have in 5.0) any implementors of
#primitiveEnterCriticalSectionOnBehalfOf: or
#primitiveTestAndSetOwnershipOfCriticalSectionOnBehalfOf:.

It used to simulate new lock primitives which I think not used in system

Bert Freudenberg

Re: Why "context top" points to "tempVector" and not to variable value?

In reply to this post by Chris Muller-3

On 11.05.2016, at 23:10, Chris Muller <[hidden email]> wrote:

>
> Great discussion, the debugger is the most powerful browser.
> Unfortunately, we still have this very painful and highly occurring
> bug that renders debugging "Through" essentially too dangerous to use
> at all..
>
> For example:
>
> SearchTopic new updateContents
>
> Shift+Cmd+D to "Debug it", then press Through Through (i.e., step
> through "updateContents").
>
> ... you now have an inescapable Emergency Evaluator.

Alt-. gets you out.

But yes, there’s something seriously wrong.

- Bert -

smime.p7s (5K) Download Attachment