Explanation.
When the debugger steps a method it obtains a map of the
bytecodes from the compiler. This maps bytecodes to the
source code text position. Entries in the map are also used
to tell the debugger where it needs to stop bytecode stepping
for each logical source code step. It would appear that,
due to changes in the compiler, the map generated by vw 7.5
can be out of sync for a method compiled in an earlier version.
In addition to causing a problem with the debugger stepping,
this may also cause a problem when attempting to insert a
breakpoint into the method while in the debugger. Inserting
a breakpoint from the browser should not cause a problem
because the method is recompiled, although this should be
checked out.
Recompiling all the methods by the 7.5 compiler would be the
obvious fix. But, this also means that when an older parcel
is loaded, its methods will also have to be recompiled.
Terry
===========================================================
Terry Raymond
Crafted Smalltalk
80 Lazywood Ln.
Tiverton, RI 02878
(401) 624-4517
[hidden email]
<
http://www.craftedsmalltalk.com>
===========================================================
> -----Original Message-----
> From:
[hidden email] [mailto:
[hidden email]] On Behalf
> Of Steve Aldred
> Sent: Wednesday, March 12, 2008 11:11 PM
> To: vwnc-list
> Subject: [vwnc] Old bytecode for Timestamp>>#addSeconds: in stock 7.5
> image
>
> In a stock VWNC 7.5 image, stepping the following code in a debugger
> results in strange behaviour.
>
> Timestamp now addSeconds: 5
>
> After the large integer (86400) is processed the debugger gets out of
> sync with execution. So executing #+ displays fine, but it then goes on
> and displays as though it's about to execute #\\, but the stack shows
> that it is actually starting to execute the next line (Time is on the
> stack).
>
> Recompiling #addSeconds: results in different bytecode than came with
> the image. The constant 86400 is stored as a literal instead of inline
> in the bytecode. After recompiling this problem no longer happens.
>
> We're able to work around this, so it isn't a big issue, but thought we
> should mention it in case there are other methods in the image that also
> have this problem. Perhaps recompiling all methods as part of the build
> process could fix these?
>
> David and Steve
>
> _______________________________________________
> 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
Locked
