Problem setting a breakpoint in the last line of a method (in 7.4)

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
2 messages Options
Reply | Threaded
Open this post in threaded view
|

Problem setting a breakpoint in the last line of a method (in 7.4)

Sonia Chase
We are seeing a walkback, "Unhandled exception: Subscript out of
bounds", when trying to set a breakpoint in the last line of a method
similar to this one:

someMethod
   true
       ifTrue: [
           true
               ifTrue: [String new]]

The problem happens when setting the breakpoint, not during execution of
the method so it is easy to reproduce.  We kept taking things out of our
method that we originally found the problem in until we could reproduce
the problem in a 7.4 visual.im image with the code we have above.  Yes,
this code is meaningless, but in its simplicity it showcases the problem
without distractions.

If you add a period to the end of the method and then another line of
code, then the problem goes away.   A period by itself is not enough.  
Adding another line of code within the second ifTrue: block doesn't have
any effect on the situation.

someMethod2
   true
       ifTrue: [
           true
               ifTrue: [String new]].
   self halt.

If you make the modification to add the self halt at the end, then you
can set a breakpoint in the 'String new' line.   After successfully
setting that breakpoint, try setting another one anywhere in the
method.   Now you will get an "Unhandled exception: Message not
understood: #first".   This is probably just a side effect of the first
problem, but I have included it because sometimes a problem can be
debugged easier from its side effects than from the original walkback.

Regards,
Sonia Chase
Adventa Control Technologies, Inc.
3001 E. Plano Parkway, #100
Plano, TX 75074-7422
Office: 972.543.1688
FAX: 972.633.9317
http://www.adventact.com
mailto:[hidden email] <mailto:[hidden email]>

Reply | Threaded
Open this post in threaded view
|

RE: Problem setting a breakpoint in the last line of a method (in 7.4)

Terry Raymond
Sonia

I was able to reproduce the problem, and also confirm
that it does not occur in 7.4.1.

Terry
 
===========================================================
Terry Raymond       Smalltalk Professional Debug Package
Crafted Smalltalk
80 Lazywood Ln.
Tiverton, RI  02878
(401) 624-4517      [hidden email]
<http://www.craftedsmalltalk.com>
===========================================================

> -----Original Message-----
> From: Sonia Chase [mailto:[hidden email]]
> Sent: Wednesday, April 18, 2007 6:01 PM
> To: [hidden email]; [hidden email]
> Subject: Problem setting a breakpoint in the last line of a method (in
> 7.4)
>
> We are seeing a walkback, "Unhandled exception: Subscript out of
> bounds", when trying to set a breakpoint in the last line of a method
> similar to this one:
>
> someMethod
>    true
>        ifTrue: [
>            true
>                ifTrue: [String new]]
>
> The problem happens when setting the breakpoint, not during execution of
> the method so it is easy to reproduce.  We kept taking things out of our
> method that we originally found the problem in until we could reproduce
> the problem in a 7.4 visual.im image with the code we have above.  Yes,
> this code is meaningless, but in its simplicity it showcases the problem
> without distractions.
>
> If you add a period to the end of the method and then another line of
> code, then the problem goes away.   A period by itself is not enough.
> Adding another line of code within the second ifTrue: block doesn't have
> any effect on the situation.
>
> someMethod2
>    true
>        ifTrue: [
>            true
>                ifTrue: [String new]].
>    self halt.
>
> If you make the modification to add the self halt at the end, then you
> can set a breakpoint in the 'String new' line.   After successfully
> setting that breakpoint, try setting another one anywhere in the
> method.   Now you will get an "Unhandled exception: Message not
> understood: #first".   This is probably just a side effect of the first
> problem, but I have included it because sometimes a problem can be
> debugged easier from its side effects than from the original walkback.
>
> Regards,
> Sonia Chase
> Adventa Control Technologies, Inc.
> 3001 E. Plano Parkway, #100
> Plano, TX 75074-7422
> Office: 972.543.1688
> FAX: 972.633.9317
> http://www.adventact.com
> mailto:[hidden email] <mailto:[hidden email]>