[bug] Missing variables in debugger

Execute the following in 5.1.3:

    (1 to: 5) do: [:a | a + 2].
    (11 to: 15) do: [:b | b * 2].
    (21 to: 25) do: [:c | c = 23 ifTrue: [self halt]].

Open the debugger. After the variable "self" with a value of nil, you'll
see two unnamed variables with values 5 and 15, the final values for "a"
and "b" which are now out of scope. This is as it should be. (I
understand that in Dolphin 6 they'll be gone entirely, but in 5 their
values are still on the stack).

But, the variable "c" and its value are nowhere to be found.

-------------------------------------------
Bill Dargel            [hidden email]
Shoshana Technologies
100 West Joy Road, Ann Arbor, MI 48105  USA

Bill,

>
>     (1 to: 5) do: [:a | a + 2].
>     (11 to: 15) do: [:b | b * 2].
>     (21 to: 25) do: [:c | c = 23 ifTrue: [self halt]].
[]
> But, the variable "c" and its value are nowhere to be found.

FWIW - In the past I've found that forcing the breakpoint in a different
way works well

(21 to: 25) do: [:c | c = 23 ifTrue: [c crashAndBurn]].

and is still resumable.  You can also "tweak" the original to get it to
show c

(21 to: 25) do: [:c | (c = 23) | (c = 23) ifTrue: [self halt]].
(21 to: 25) do: [:c | c = 23 & true ifTrue: [self halt]].
(21 to: 25) do: [:c | c = (22 + 1) ifTrue: [self halt]].

"and even - works on the second halt"
(21 to: 25) do: [:c | c = 23 ifTrue: [self halt]. c = 23 ifTrue: [self
halt]].

--
Ian

Use the Reply-To address to contact me.
Mail sent to the From address is ignored.

Ian Bartholomew wrote:
Hmm. When I try that in place of the original, I still don't see "c" in
the context of the above method. Granted, one can see its value as the
receiver of the #crashAndBurn message. But that seems to really just be
a workaround to not being able to see it in the debugger the original
way, and knowing ahead of time that the variable "c" is what will be
missing.

Actually, where I first ran into the issue was with a unit test. It had
an #assert: that was failing (rather than a self halt). I just wanted to
see which element in a loop had caused the problem, but "each" was
nowhere to be found in the debugger.

>
> and is still resumable.  You can also "tweak" the original to get it to
> show c
>
> (21 to: 25) do: [:c | (c = 23) | (c = 23) ifTrue: [self halt]].
> (21 to: 25) do: [:c | c = 23 & true ifTrue: [self halt]].
> (21 to: 25) do: [:c | c = (22 + 1) ifTrue: [self halt]].
>

Yep, sure is something strange all right. I found that you can also get
"c" to show by changing the original second line to be:

    (11 to: 15) do: [:b | ].

Bottom line is that there's some sort of bug in the debugger. Apparently
introduced with 5.1? At least the original does show "c" in 5.0.3.

Just thought that I'd pass what I found on to Andy and Blair as an
easily reproducible example.

-------------------------------------------
Bill Dargel            [hidden email]
Shoshana Technologies
100 West Joy Road, Ann Arbor, MI 48105  USA

Bill,

> Hmm. When I try that in place of the original, I still don't see "c"
> in the context of the above method. Granted, one can see its value as
> the receiver of the #crashAndBurn message. But that seems to really
> just be a workaround to not being able to see it in the debugger the
> original way, and knowing ahead of time that the variable "c" is what
> will be missing.
[]
> Just thought that I'd pass what I found on to Andy and Blair as an
> easily reproducible example.

Sorry, I didn't mean to give the impression that it wasn't a problem or
that my suggestion was a solution.  It was just a way (yes, a
workaround) of  making the loop value visible at a breakpoint without
having to change too much code.  I do quite a bit of experimenting using
workspaces and I've come across the problem a few times recently so I
was just aware of this "easy" workaround.

--
Ian

Use the Reply-To address to contact me.
Mail sent to the From address is ignored.

Bill, Blair,

> Bottom line is that there's some sort of bug in the debugger. Apparently
> introduced with 5.1? At least the original does show "c" in 5.0.3.

I am forced to agree.  On qualitative grounds, I find the debugger
significantly less helpful since moving to 5.1, and the disappointment
always surrounds not being able to see or even inspect something that
"feels" like it should be in scope - perhaps I'm wrong on that point.

Just this afternoon, and independent of the above observation, I had Dolphin
crash on me, which is something that does not happen very often.  I will try
to send Blair a copy of the offending code.  It involves a super send to an
Object method having a temporary #name, with some confusion surrounding a
#name instance variable in a subclass.  This is probably one of those minor
problems that turns out to cause significant grief, but the debugger appears
to be genuinely confused by it, with unfortunate results.  Of course, the
confusion could be rooted in a mistake that corrupts something to the point
that the debugger would not be expected to work correctly.

Ok,  I'm off in search of a reproducible example =:0

Have a good one,

Bill

--
Wilhelm K. Schwab, Ph.D.
[hidden email]

Blair,

> Just this afternoon, and independent of the above observation, I had
Dolphin
> crash on me, which is something that does not happen very often.  I will
try
> to send Blair a copy of the offending code.  It involves a super send to
an
> Object method having a temporary #name, with some confusion surrounding a
> #name instance variable in a subclass.  This is probably one of those
minor
> problems that turns out to cause significant grief, but the debugger
appears
> to be genuinely confused by it, with unfortunate results.  Of course, the
> confusion could be rooted in a mistake that corrupts something to the
point
> that the debugger would not be expected to work correctly.

After a few more crashes, I think I found the problem.  I will send the
broken package to you, along with instructions for getting a walkback that
will (hopefully?????<g>) lead to a debugger that will eventually crash
Dolphin.

As I suspected, the problem is a programming error on my part.  I will leave
it to you to judge whether the collateral damage is sufficient to cause a
crash.  This isn't quite as bad as the time I overrode #name on the class
side<g>, but it's close.

Have a good one,

Bill

--
Wilhelm K. Schwab, Ph.D.
[hidden email]

Blair,

With luck, you will get an email with an attached package (broken version)
and a hot fix in the body of the email.  Making a long story short, I caused
a recursion in a #printOn:.  If you decide that the punishment fits the
crime, so be it.  If not, maybe the example will help you sort out a
problem.

Have a good one,

Bill

--
Wilhelm K. Schwab, Ph.D.
[hidden email]

"Bill Schwab" wrote

> ... On qualitative grounds, I find the debugger
> significantly less helpful since moving to 5.1, and the disappointment
> always surrounds not being able to see or even inspect something that
> "feels" like it should be in scope ...

Very well said, Bill - I agree too.  I've learned to cope with it, but it
seems a step backwards.

-- Louis

"Louis Sumberg" <[hidden email]> wrote in message
news:brvuar$7sjlk$[hidden email]...
Well if we are voting on this then I cast my vote for "the debugger scope
bug is annoying" as well. ;)  I did not pay attention to what version of
Dolphin the problem started in, but I have run into this quite a bit.
Sometimes it is slightly annoying, and something's it is really annoying.  I
hope this can be fixed in D6 or even better in PL4.  The debugger needs some
debugging. ;)

Chris

Chris,

> Well if we are voting on this then I cast my vote for "the debugger scope
> bug is annoying" as well. ;)  I did not pay attention to what version of
> Dolphin the problem started in, but I have run into this quite a bit.
> Sometimes it is slightly annoying, and something's it is really annoying.
I
> hope this can be fixed in D6 or even better in PL4.

Well, while we're voting, let's hear it for a fix in PL4 :)  I should
confess that my reference to 5.1 is based on a couple of things, neither of
which is scientific.  First, some of our peers have reported similar
problems starting in 5.1 and absent in 5.0.x, and my complaints are
analogous to theirs.  Second, my adoption of 5.1 was delayed by a tapestry
of mistakes, all but one made by your truly =:0   It took some time to sort
that out, and then some more time to address shutdown problems in 5.1.  The
debugger scope problems are relatively recent for me, hence I would localize
them to 5.1.

Have a good one,

Bill

--
Wilhelm K. Schwab, Ph.D.
[hidden email]

"Bill Dargel" <[hidden email]> wrote in message
news:[hidden email]...
This is a known bug in the compiler Bill (search the newsgroup archives for
the thread "block temps not in scope in the debugger?" for more info). The
problem is that the maps it builds between instruction pointer ranges and
the temps in scope in those ranges are sometimes incorrect. The 5.1 Compiler
fixed a number of longstanding compiler bugs (there were 8 bug fixes and 9
enhancements in the 5.1 compiler). Most of these changes were made by back
porting from D6, but unfortunately not all of the changes were completely
compatible due to the different block implementations. The problem is
probably somewhat worse than I'd realised, so we'll try and make a new
compiler available for PL4.

Regards

Blair

"Bill Schwab" <[hidden email]> wrote in message
news:brvs6h$871h3$[hidden email]...
> ...
> After a few more crashes, I think I found the problem.  I will send the
> broken package to you, along with instructions for getting a walkback that
> will (hopefully?????<g>) lead to a debugger that will eventually crash
> Dolphin.
>
> As I suspected, the problem is a programming error on my part.  I will
leave
> it to you to judge whether the collateral damage is sufficient to cause a
> crash.  This isn't quite as bad as the time I overrode #name on the class
> side<g>, but it's close.

Bill, what is happening here is an unrecoverable stack overflow. In Dolphin
activation records are held with the Process objects as stacks reserved from
virtual memory. As the stack grows further pages are committed. Eventually a
high water mark may be hit, and a stack overflow exception is raised in the
process resulting in a walkback. The high water mark is a soft limit, and a
further page is committed to permit the process to be debugged. The debugger
runs in the context of the debugged process, so its own frames will need
further space on the stack (hence the soft limit). There is, however, a hard
limit that will eventually be hit and no further pages can be committed. If
you have a recursive #printOn: implementation that is used by the debugger
for its displays, then this might cause an unrecoverable stack overflow in
the debugger as follows: Errors occurring in the debugged process are
directed to the debugger, rather than causing a further walkback. On receipt
of an error notification debugger will attempt to update its display to show
the new error. If the error was a further stack overflow, then this might
lead to a further stack overflow. Eventually the stack will be exhausted,
and the system will crash.

I don't think the handling of this situation is very friendly, so I'll
record a defect so it can be looked at at some point. In the meantime if you
see a stack overflow resulting from an infinitely recursive #printOn:
implementation don't attempt to debug it without first adding a
#debugPrintString method that is guaranteed to work.

Regards

Blair

Blair,

> I don't think the handling of this situation is very friendly, so I'll
> record a defect so it can be looked at at some point.

Fair enough.


> In the meantime if you
> see a stack overflow resulting from an infinitely recursive #printOn:
> implementation don't attempt to debug it without first adding a
> #debugPrintString method that is guaranteed to work.

Will do.  Thanks!

Have a good one,

Bill

--
Wilhelm K. Schwab, Ph.D.
[hidden email]