On Wed, Jul 04, 2018 at 02:35:59PM +0200, karl ramberg wrote:
> 
> On Wed, Jul 4, 2018 at 11:10 AM K K Subbu <kksubbu.ml at gmail.com> wrote:
> 
> > On Tuesday 03 July 2018 04:40 AM, Tim Johnson wrote:
> > > 1. File-in the .cs as attached*.
> > > 2. In a system browser, click on the class, then click on the [?] button
> > > to view class comment.
> > > 3. Notice the styled text in the comment.
> > > 4. Click around the comment pane a bit.
> > > 5. Eventually, see "Error: subscript is out of bounds: 71" appear over
> > > and over until you interrupt.
> > In step 4, it is sufficient to click once near the bottom of the pane
> > when the cursor changes from I-bar to arrow and then wait. This will
> > trigger the error, but the error window triggers itself recursively
> > around 50 times before stopping and displaying the windows.
> >
> > I added an assert to catch it before recursion:
> >
> >     self assert: lastIndex < sourceString size.
> >
> > The assert window itself throws up another error, but that is a topic
> > for another thread ;-).
> >
> > Regards .. Subbu

> 
> Hi,
> See class comment i NewParagraph for a hint of what happens.
> A empty lineSpan 71 to: 70 is added to the end of the paragraph, when you
> double click below the text.
> When the character scanner looks for characters outside of the string at
> index 71 it cause a recursion.
> 
> Best,
> Karl
> 

Good tiip to look at the NewParagraph class comment, there is apparently
some left over messiness in here somewhere.

Another way to trigger the bug using the test case with FooClient is
to position the cursor in the comment pane and use keyboard right cursor
to move to the end of the comment. This causes the same bounds error but
takes a different path through the code leading to the error.

Looking through the stack in a debugger after triggering the error with
the mouse, here are a few notes (but no conclusions):

On mouseUp: we enter Editor>>selectWord then call Editor>>selectWordLeftDelimiters:rightDelimiters:
which has this:

	"Select the whole text when clicking before first or after last character"
	(here > string size or: [here < 2]) ifTrue: [^self selectFrom: 1 to: string size].

where string is the 70 character String derived from the Text.

At this point we are trying to select from 1 to 70 (the whole string for
the entire text) in TextEditor>>selectFrom:to:

This calls Editor>>selectInvisiblyFrom:to: and here the stop index is
set past the size of the string:

  selectInvisiblyFrom: start to: stop
     "Select the designated characters, inclusive.  Make no visual changes."

     self markIndex: start pointIndex: stop + 1

>From this point we are trying to go from index 1 to index 71 over a string
of size 70, and eventually end up with the out of bounds exception.

A clue that this might be accumulation of kludges: Looking at senders of
selectInvisiblyFrom:to: (such as TextEditor>>addText:event:) shows a number
of methods that subtract 1 from the stop index when before calling the method
that adds 1 back to the stop index. This certainly does not have a good smell.

It is not clear to me why selectInvisiblyFrom:to: would be adding one to the
stop index, but I see that the method stamp is jmv 5/27/2011, which suggests
to me that we should take a look at Cuis to figure out how this is intended
to function. Cuis does not show any cases of senders of selectInvisiblyFrom:to:
that subtract 1 from the stop index, and the Cuis implementation of
selectInvisiblyFrom:to: is that same as Squeak.

Dave