[squeak-dev] Debugger bug: disappearing contents
Eliot Miranda
eliot.miranda at gmail.com
Thu Dec 2 16:52:38 UTC 2010
On Thu, Dec 2, 2010 at 8:40 AM, Frank Shearar
<frank.shearar at angband.za.org>wrote:
> On 2010/12/01 17:33, Eliot Miranda wrote:
>
>>
>>
>> On Wed, Dec 1, 2010 at 7:10 AM, Frank Shearar
>> <frank.shearar at angband.za.org <mailto:frank.shearar at angband.za.org>>
>> wrote:
>>
>> On 2010/11/21 15:47, Frank Shearar wrote:
>>
>> On 2010/11/13 17:35, Frank Shearar wrote:
>>
>> Hi,
>>
>> I've been chasing down a strange bug these past few days:
>> http://bugs.squeak.org/view.php?id=7569
>>
>> The executive summary is this: when viewing a method in the
>> debugger
>> that refers to an instvar deleted after the Debugger
>> instantiated, the
>> CodePane shows the correct source for a fraction of a
>> second, and then
>> goes blank.
>>
>> What I'd expected to see was the source of the method
>> rendered as per
>> usual, and the reference to the missing instvar coloured red,
>> to
>> indicate a problem. (Just like what you'd see if you opened
>> up a Browser
>> on the method.)
>>
>> The CodePane goes blank because the Debugger's contents
>> instvar is
>> nilled out.
>>
>> CodeHolder>>setContentsToForceRefresh nils the instvar because
>> CodeHolder>>didCodeChangeElsewhere returns true.
>>
>> That method returns true because the Debugger's
>> currentCompiledMethod
>> instvar and the compiled method according to "aClass
>> compiledMethodAt:
>> aSelector" aren't the same object.
>>
>> And now I'm a bit stuck. I know the behaviour I'd expect, I
>> know why the
>> bug's happening, but how do I fix it? Does CodeHolder (or
>> Debugger) need
>> a better way of knowing whether the viewed method's changed?
>> (For
>> instance, comparing the two CompiledMethods' asCommaString
>> shows
>> identical contents.)
>>
>>
>> OK, I got a bit further. The Debugger's absolutely right in
>> saying that
>> the code has changed elsewhere. As soon as you delete the
>> instvar, the
>> entire class is recompiled and, in particular, the method
>> referencing
>> the deleted instvar changes.
>>
>> In my tests my method #bar looks like this:
>>
>> bar
>> self halt.
>> baz := 1.
>>
>> with bytecodes
>>
>> 17 <70> self
>> 18 <D0> send: halt
>> 19 <87> pop
>> 20 <76> pushConstant: 1
>> 21 <60> popIntoRcvr: 0
>> 22 <78> returnSelf
>>
>> After deleting the instvar baz, bar's bytecodes look like this:
>>
>> 21 <70> self
>> 22 <D0> send: halt
>> 23 <87> pop
>> 24 <76> pushConstant: 1
>> 25 <82 C1> popIntoLit: baz
>> 27 <78> returnSelf
>>
>> I can't argue with that. It does mean that the Debugger's job is
>> harder.
>> In this particular case, nilling out the Debugger's contents is the
>> wrong thing to do, because it's surprising. You see the code,
>> see the
>> reference to the defunct instvar... and then your source is gone!
>>
>> We fall into this hole because for most CodeHolders, when the
>> code's
>> changed, self hasUnacceptedEdits will return true, and you'll
>> get that
>> red border around your code. In this case, there aren't
>> unaccepted edits
>> because the user hasn't changed code. Instead, the Debugger has
>> what I
>> suppose one might call a stale copy of the method (in
>> contextStack).
>>
>> So what should the correct behaviour be? How about a message
>> that says
>> "Oops, this method has changed underneath your feet. Would you
>> like to
>> revert back to the context that called it?"
>>
>>
>> I have something that works but, seeing as this is the Debugger, I'd
>> appreciate someone else having a look.
>>
>> It's in Tools-fbs.283, in the Inbox.
>>
>>
>> Looks good to me, but it might be wise to check that selectedContext is
>> not nil. Theres' an assumption that contextStackTop is always valid and
>> I can imagine that changing. Something like
>>
>> contents
>> "Depending on the current selection, different information is retrieved.
>> Answer a string description of that information. This information is the
>> method in the currently selected context."
>>
>> ^contents ifNil:
>> [self selectedContext
>> ifNotNil: [self selectedMessage]
>> ifNil: [String new]]
>>
>> BTW, Personally I don't like the top context being shown when nothing is
>> selected in stack list Is contextStackTop really necessary?
>>
>
> I wondered that myself, as I hacked on this.
>
> With your change you will still see the top context when nothing's
> selected, at least once you have selected something. (But at first, if the
> debugger pops up and you hit "debug", then the code pane's blank.)
>
> And you'll see that top context precisely because there's no concept of
> "nothing selected" - contextStackIndex = 0 means "show contextStackTop", and
> contextStackIndex > 0 means "you've selected something in the list of
> contexts".
>
Right. And IMO that's a bug.
>
> Both your version and mine at least address
> http://bugs.squeak.org/view.php?id=7569
>
> frank
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.squeakfoundation.org/pipermail/squeak-dev/attachments/20101202/25f546be/attachment.htm
More information about the Squeak-dev
mailing list
|