#3307 repeatable NPE in selection S&R with undo

[Kevin Hunter Kesling]

With r15864, I'm able to repeat an NPE utilizing the S&R dialog:

1. Create some filler text to more-than-fill the screen. The TextArea should need to scroll to view the entire buffer.
2. Select All
3. Ctrl+F (or otherwise open the Search and Replace dialog box)
4. Make sure the 'Selection' radio option is selected in the "Search In" section
5. Search for: '\n*'
6. Replace with: '\n'
7. Go to the TextArea, and undo what you just did.
8. Try to scroll, or move the cursor to view text not in view.

TextArea NPE achieved.

[Kevin Hunter Kesling]

Traceback associated with NPE caused

[Dennis Sheil]

I reproduced this a number of times.

I am running a Linux system, Gnewsense, which is a modified version of Ubuntu Hardy. Running Java SE 6. Running the latest jEdit - revision 15872.

One thing to note is not only does the Selection radio tab need to be selected, but I believe the regular expressions box needs to be marked in the search/replace box as well.

As the NPE happens in the scrollTo method, I set SCROLL_TO_DEBUG to true in Debug.java

I repeat the procedure given above and here is the activity.log when the NPE happens -

10:00:55 PM [AWT-EventQueue-0] [debug] EditBus: SearchSettingsChanged[source=null]
10:01:14 PM [AWT-EventQueue-0] [debug] EditBus: PositionChanging[what=POSITION_CHANGING,source=org.gjt.sp.jedit.EditPane[active,global]]
10:01:14 PM [AWT-EventQueue-0] [debug] JEditTextArea: scrollTo(), lineCount=11290
10:01:15 PM [AWT-EventQueue-0] [debug] JEditTextArea: scrollTo(), lineCount=103
10:01:15 PM [AWT-EventQueue-0] [debug] JEditTextArea: electric up
10:01:18 PM [AWT-EventQueue-0] [debug] JEditTextArea: scrollTo(), lineCount=103
10:01:18 PM [AWT-EventQueue-0] [debug] JEditTextArea: scrollTo(), lineCount=103
10:01:18 PM [AWT-EventQueue-0] [debug] JEditTextArea: screenLine == -1
10:01:18 PM [AWT-EventQueue-0] [debug] JEditTextArea: neither
10:01:18 PM [AWT-EventQueue-0] [debug] JEditTextArea: Last physical line is 28
10:01:18 PM [AWT-EventQueue-0] [debug] JEditTextArea: Last physical line is 28
10:01:18 PM [AWT-EventQueue-0] [error] BeanShellAction: java.lang.NullPointerException
10:01:18 PM [AWT-EventQueue-0] [error] BeanShellAction: at org.gjt.sp.jedit.textarea.TextArea.scrollTo(TextArea.java:876)
10:01:18 PM [AWT-EventQueue-0] [error] BeanShellAction: at org.gjt.sp.jedit.textarea.TextArea.scrollToCaret(TextArea.java:733)

That line that says screenLine equals -1 is correct, I did test modifications of the code to verify that.

So considering that screenLine is -1, here is the beginning of the problem -

On line 874 of TextArea.java, an object point, of class Point is to be created. On line 876 the value of an integer belonging to point is to be changed.

The code is -

Point point = offsetToXY(line,offset,offsetXY);
point.x += extraEndVirt;

So obviously the offsetToXY method needs to return a Point object. So let us look at that method when the above parameters are given (lines 1085-1091 of TextArea.java)

public Point offsetToXY(int line, int offset, Point retVal)
{
if(!displayManager.isLineVisible(line))
return null;
int screenLine = chunkCache.getScreenLineOfOffset(line,offset);
if(screenLine == -1)
return null;

[...]

It says if screenLine is equal to -1, a null is returned as opposed to a Point object. But as we saw, on line 876, numbers are being added to the integer x that is in the point object. As the point object is null, we get the Null Pointer Exception.

[Anonymous]

The issue is not related to selection, the bug can be reproduced simply moving to the end of the file before pressing Ctrl+F (and using "Replace all" instead of the "Selection" radio button). The problem seems to be the fact that "Undo" moves the caret to the point where the first change occurred (in this case, the first "\n" in the file), but the scroll position is not updated, so even though the caret is moved to the first line, the scrollbar still shows that the caret is at the end.
The next time you try to scroll down to a line that is not currently on screen, you will get the exception.

[Thomas Meyer]

Fixed by patch 3567959.