[squeak-dev] Debugger bug: disappearing contents
Frank Shearar
frank.shearar at angband.za.org
Thu Dec 2 17:48:20 UTC 2010
On 2010/12/02 16:52, Eliot Miranda wrote:
>
>
> On Thu, Dec 2, 2010 at 8:40 AM, Frank Shearar
> <frank.shearar at angband.za.org <mailto: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>
> <mailto: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
http://bugs.squeak.org/view.php?id=7575
I've also resubmitted a fix for 7569, using your version and my explanation.
frank
More information about the Squeak-dev
mailing list
|