Bugzilla – Bug 490130
RichTextBox: if input too much letters in " accerciser -> Interface Viewer -> Text" will crash the application
Last modified: 2009-08-12 14:16:08 UTC
COMMENTS Operateing the second richtextbox in "accerciser -> Interface Viewer -> Text",if input the letter all the time will crash the application REPRO 1. Run uia2atk/test/samples/richtextbox.py. 2. Open Accerciser and open the "IPython Console." 3. In Accerciser, browse to and select the second richtextbox accessible. It has a blank name and the "text" role. 4. In "Interface Viewer -> Text", there is a string:"This is some text." put the cursor into the end of the string , and input the letter "g" or else letter ceaselessly, when the "Offset" in "Interface Viewer -> Text" is as large as 1534, the application crashes. RESULTS the application crashes. EXPECTED RESULTS if the number of letter is too large, the richtextbox should not accept the inputed letters COMMENTS the log on the console is: currentFont: [Font: Name=Arial, Size=8.25, Units=3, GdiCharSet=1, GdiVerticalFont=False] newFont: Bold Exception in Gtk# callback delegate Note: Applications can use GLib.ExceptionManager.UnhandledException to handle the exception. System.ArgumentOutOfRangeException: startIndex + length > this.length Parameter name: length at System.String.Substring (Int32 startIndex, Int32 length) [0x00085] in /usr/src/packages/BUILD/mono-2.4/mcs/class/corlib/System/String.cs:370 at Mono.UIAutomation.Winforms.TextRangeProvider.GetText (Int32 maxLength) [0x0004e] in /usr/src/packages/BUILD/uiautomationwinforms-1.0+129584/UIAutomationWinforms/Mono.UIAutomation.Winforms/TextRangeProvider.cs:326 at UiaAtkBridge.TextProviderTextImplementor.get_Text () [0x00000] in /usr/src/packages/BUILD/uiaatkbridge-1.0+129584/UiaAtkBridge/TextProviderTextImplementor.cs:42 at UiaAtkBridge.BaseTextImplementor.get_Length () [0x00000] in /usr/src/packages/BUILD/uiaatkbridge-1.0+129584/UiaAtkBridge/BaseTextImplementor.cs:46 at UiaAtkBridge.TextProviderTextImplementor.GetRunAttributes (Int32 offset, System.Int32& startOffset, System.Int32& endOffset) [0x00000] in /usr/src/packages/BUILD/uiaatkbridge-1.0+129584/UiaAtkBridge/ActionImplementorHelper.cs:1 at UiaAtkBridge.TextBoxEntryView.GetRunAttributes (Int32 offset, System.Int32& startOffset, System.Int32& endOffset) [0x00000] in /usr/src/packages/BUILD/uiaatkbridge-1.0+129584/UiaAtkBridge/TextBoxEntryView.cs:132 at Atk.TextAdapter.GetRunAttributesCallback (IntPtr text, Int32 offset, System.Int32& start_offset, System.Int32& end_offset) [0x0000d] in /usr/src/packages/BUILD/gtk-sharp-126100/atk/generated/TextAdapter.cs:171 at GLib.ExceptionManager.RaiseUnhandledException(System.Exception e, Boolean is_terminal) in /usr/src/packages/BUILD/gtk-sharp-126100/glib/ExceptionManager.cs:line 58 at Atk.TextAdapter.GetRunAttributesCallback(IntPtr text, Int32 offset, Int32 ByRef start_offset, Int32 ByRef end_offset) in /usr/src/packages/BUILD/gtk-sharp-126100/atk/generated/TextAdapter.cs:line 174 at GLib.MainLoop.g_main_loop_run(IntPtr ) at GLib.MainLoop.Run() in /usr/src/packages/BUILD/gtk-sharp-126100/glib/MainLoop.cs:line 59 at UiaAtkBridge.Monitor.GLibMainLoopThread() in /usr/src/packages/BUILD/uiaatkbridge-1.0+129584/UiaAtkBridge/Monitor.cs:line 145 Segmentation fault
This is definitely interesting. Although I cannot replicate the crashing problem, I am definitely seeing weird behavior. The weird behavior that I am seeing is that when holding down a key to insert a lot of text, all of the text in the sample application and in Accerciser's "Text" field disappears and the text being inserted starts from the beginning again. However, this behavior seems to be caused by the fact that the character is being inserted too rapidly. For example, when I insert a character repeatedly into Accerciser's "Text" field without letting up on the key, that is when I begin to see problems once a lot of characters have been inserted. However, if I input the characters by tapping the key repeatedly (i.e., not holding the key down), I do not see the problem. One thing you can try to replicate is to do the following: 1. Open uia2atk/test/samples/richtextbox.py 2. In Accerciser, browse to and select the text accessible representing the lower textbox in the sample application 3. In Accerciser's IPython Console run the following: eti = acc.queryEditableText() eti.insertText(18, <a 2500-character string>, 2500) 4. In Accerciser's Interface Viewer -> Text field, tap a key repeatedly (i.e., do not hold the key down) 100 or so times. I was not seeing any weird behavior when doing this. 5. In Accerciser's Interface Viewer -> Text field, hold a key down until weird behavior occurs. I saw weird behavior soon after doing this each time (within a few seconds). I will attach the 2500-character string. This is a weird enough case that I'm not sure how much we should worry about it. However, I could not replicate any problems (other than things slowing down dramatically) when running these steps. I am marking this as a P4 for now, but I'm CCing Brad because it is crashing for Felicia.
Created attachment 283002 [details] 2500-character text file, referenced in Comment #1's repro steps.
Oops! In my second-to-last paragraph in Comment #1, I meant to say that I could not replicate any problems (other than things slowing down dramatically) when running these steps in Gtk.
I can reproduce both crashing problem and text bing inserted start from the beginning again problem. I got the same exception as Description when I holding down a key to insert about 531 texts.
hi Brian , if you cannot replicate the crashing problem, maybe there's another way: 1. Run uia2atk/test/samples/richtextbox.py. 2. Open Accerciser and open the "IPython Console." 3. In Accerciser, browse to and select the second richtextbox accessible. It has a blank name and the "text" role. 4. In the IPython console, run the following lines: eti = acc.queryEditableText() eti.insertText(18,"a",1) the output of the second richtextbox is :"This is some text.a" 5. In the IPython console, run the following lines: eti.insertText(19, 123456789*"b", 123456789) the output of the second richtextbox is :"This is some text.a" (the output is not correct), and about 2 or 3 seconds later, the sample application crashed. the log on the terminal is: currentFont: [Font: Name=Arial, Size=8.25, Units=3, GdiCharSet=1, GdiVerticalFont=False] newFont: Bold Traceback (most recent call last): File /usr/src/packages/BUILD/uiautomationwinforms-1.0+129584/UIAutomationWinforms/Mono.UIAutomation.Winforms.Behaviors/TextBox/ValueProviderBehavior.cs, line 128, in PerformSetValue File /usr/src/packages/BUILD/mono-2.4/mcs/class/Managed.Windows.Forms/System.Windows.Forms/RichTextBox.cs, line 755, in set_Text File /usr/src/packages/BUILD/mono-2.4/mcs/class/Managed.Windows.Forms/System.Windows.Forms/TextBoxBase.cs, line 656, in set_Text File /usr/src/packages/BUILD/mono-2.4/mcs/class/Managed.Windows.Forms/System.Windows.Forms/TextControl.cs, line 1973, in Insert File /usr/src/packages/BUILD/mono-2.4/mcs/class/Managed.Windows.Forms/System.Windows.Forms/TextControl.cs, line 1996, in Insert File /usr/src/packages/BUILD/mono-2.4/mcs/class/Managed.Windows.Forms/System.Windows.Forms/Line.cs, line 437, in InsertString File /usr/src/packages/BUILD/mono-2.4/mcs/class/Managed.Windows.Forms/System.Windows.Forms/Line.cs, line 404, in Grow File richtextbox, line unknown, in Initialize File /usr/src/packages/BUILD/mono-2.4/mcs/class/Managed.Windows.Forms/System.Windows.Forms/Application.cs, line 740, in Run File /usr/src/packages/BUILD/mono-2.4/mcs/class/Managed.Windows.Forms/System.Windows.Forms/Application.cs, line 761, in Run File /usr/src/packages/BUILD/mono-2.4/mcs/class/Managed.Windows.Forms/System.Windows.Forms/Application.cs, line 891, in RunLoop File /usr/src/packages/BUILD/mono-2.4/mcs/class/Managed.Windows.Forms/System.Windows.Forms/XplatUI.cs, line 725, in GetMessage File /usr/src/packages/BUILD/mono-2.4/mcs/class/Managed.Windows.Forms/System.Windows.Forms/XplatUIX11.cs, line 4490, in GetMessage File /usr/src/packages/BUILD/mono-2.4/mcs/class/Managed.Windows.Forms/System.Windows.Forms/XplatUIDriver.cs, line 492, in ExecuteClientMessage File /usr/src/packages/BUILD/mono-2.4/mcs/class/corlib/System.Threading/ExecutionContext.cs, line 140, in Run File /usr/src/packages/BUILD/mono-2.4/mcs/class/corlib/System.Security/SecurityContext.cs, line 150, in Run File /usr/src/packages/BUILD/mono-2.4/mcs/class/Managed.Windows.Forms/System.Windows.Forms/XplatUIDriver.cs, line 479, in ExecutionCallback File /usr/src/packages/BUILD/mono-2.4/mcs/class/corlib/System/Delegate.cs, line 402, in DynamicInvoke File /usr/src/packages/BUILD/mono-2.4/mcs/class/corlib/System/MulticastDelegate.cs, line 71, in DynamicInvokeImpl File /usr/src/packages/BUILD/mono-2.4/mcs/class/corlib/System/Delegate.cs, line 430, in DynamicInvokeImpl StandardError: Exception has been thrown by the target of an invocation. Segmentation fault
Weird. I wonder if event handling can be re-entrant.
This is definitely a re-entrancy problem. Let me summarize my thoughts here: - Accerciser calls insertText which comes over on to our side via TextBoxEntryView.InsertText - The adapter hands it off to EditableTextImplementorHelper - Line 119 queries for the text before setting the value. In certain cases, when S.W.F's TextBoxBase:set_Text is doing its magic: if ((value != null) && (value != "")) { document.Empty (); document.Insert (document.GetLine (1), 0, false, value); document.PositionCaret (document.GetLine (1), 0); document.SetSelectionToCaret (true); a get_Text call can interrupt it, and does between document.Empty() and document.Insert(). This makes the EditableTextImplementorHelper.InsertText set an _empty_ value. The solution is either to wrap the SWF code in a lock, or more globally, to lock around all potentially re-entrant methods in the Bridge. This would be best performed by compile-time IL injection or runtime SRE wrapper classes.
Unassigning as we're focusing on the 2.0 work atm.