Take the attached text file and open it in a text editor. Now open a compose mail windows (plain text) and copy and paste the text from the text editor into the plain text compose window. Run "Options/Rewrap" Mozilla will totally freeze. I can't track down what part of the text causes rewrap to freeze eventhough I experimented quite a bit, so I am including the whole mail. The only thing I did is to search and replace quite a few letters to make the mail unreadable as it is a personal mail.

This is the text mentioned in the bug description.

Michael, please always include the build ID when reporting a bug. You can find some more useful hints in the bug reporting guidelines at http://www.mozilla.org/quality/bug-writing-guidelines.html. Please consider using Bugzilla Helper at http://www.mozilla.org/quality/help/bugzilla-helper.html to report bugs. Thanks for using Mozilla! *** This bug has been marked as a duplicate of 112139 ***

This is a different problem from the cases reported in 112139: I get into an infinite loop asserting on this: ###!!! ASSERTION: Infinite loop: can't advance a writing iterator beyond the end of a string: 'one_hop>0', file ../../../dist/include/string/nsStringIterator.h, line 330 That's all I know at this point, since gdb won't run today's mozilla build. :-(

Taking it -- but it won't make 0.9.8 unless I can get a stack trace right away, which probably means help from someone on a platform with a better debugger than gdb.

here's my stack trace (got it without gdb: setenv XPCOM_BREAK_DEBUG stack) nsDebug::Assertion(char const *, char const *, char const *, int)+0x000000A9 [/home/andrew/mozilla/dist/bin/libxpcom.so +0x000FC4E9] nsWritingIterator<unsigned short>::advance(int)+0x00000074 [/home/andrew/mozilla/dist/bin/libgkgfx.so +0x000389CC] nsAString::do_AppendFromReadable(nsAString const &)+0x000000B2 [/home/andrew/mozilla/dist/bin/libxpcom.so +0x0012114A] nsAString::AppendFromReadable(nsAString const &)+0x00000030 [/home/andrew/mozilla/dist/bin/libxpcom.so +0x00120F60] nsAString::Append(nsAString const &)+0x00000023 [/home/andrew/mozilla/dist/bin/libgkgfx.so +0x0003616B] nsAString::operator+=(nsAString const &)+0x00000021 [/home/andrew/mozilla/dist/bin/libxpcom.so +0x0015CB61] nsInternetCiter::Rewrap(nsAString const &, unsigned int, unsigned int, int, nsAString &)+0x00000932 [/home/andrew/mozilla/dist/bin/components/libeditor.so +0x0010DA4A] nsPlaintextEditor::Rewrap(int)+0x000003B7 [/home/andrew/mozilla/dist/bin/components/libeditor.so +0x000FFC93] nsEditorShell::Rewrap(int)+0x000000A1 [/home/andrew/mozilla/dist/bin/components/libcomposer.so +0x0003B05D] XPTC_InvokeByIndex+0x00000058 [/home/andrew/mozilla/dist/bin/libxpcom.so +0x00112014] XPCWrappedNative::CallMethod(XPCCallContext &, XPCWrappedNative::CallMode)+0x000011C8 [/home/andrew/mozilla/dist/bin/com ponents/libxpconnect.so +0x00070F64] XPC_WN_CallMethod(JSContext *, JSObject *, unsigned int, long *, long *)+0x000001AE [/home/andrew/mozilla/dist/bin/components/libxpconnect.so +0x00079646] js_Invoke+0x00000D10 [/home/andrew/mozilla/dist/bin/libmozjs.so +0x0004817C] js_Interpret+0x0000D2E8 [/home/andrew/mozilla/dist/bin/libmozjs.so +0x000566B4] js_Invoke+0x00000D9A [/home/andrew/mozilla/dist/bin/libmozjs.so +0x00048206] js_InternalInvoke+0x00000106 [/home/andrew/mozilla/dist/bin/libmozjs.so +0x0004857E] JS_CallFunctionValue+0x0000002F [/home/andrew/mozilla/dist/bin/libmozjs.so +0x00018D9F] nsJSContext::CallEventHandler(void *, void *, unsigned int, void *, int *, int)+0x000001E5 [/home/andrew/mozilla/dist/bin/components/libjsdom.so +0x000686F1] nsJSEventListener::HandleEvent(nsIDOMEvent *)+0x00000AC0 [/home/andrew/mozilla/dist/bin/components/libjsdom.so +0x000A7558] nsEventListenerManager::HandleEventSubType(nsListenerStruct *, nsIDOMEvent *, nsIDOMEventTarget *, unsigned int, unsigned int)+0x000006FB [/home/andrew/mozilla/dist/bin/components/libgkcontent.so +0x00272A7F] nsEventListenerManager::HandleEvent(nsIPresContext *, nsEvent *, nsIDOMEvent **, nsIDOMEventTarget *, unsigned int, nsEventStatus *)+0x00003683 [/home/andrew/mozilla/dist/bin/components/libgkcontent.so +0x002761E3] nsXULElement::HandleDOMEvent(nsIPresContext *, nsEvent *, nsIDOMEvent **, unsigned int, nsEventStatus *)+0x0000117A [/home/andrew/mozilla/dist/bin/components/libgkcontent.so +0x003AFB4E] PresShell::HandleDOMEventWithTarget(nsIContent *, nsEvent *, nsEventStatus *)+0x000000F1 [/home/andrew/mozilla/dist/bin/components/libgklayout.so +0x001C5141] nsMenuFrame::Execute(void)+0x00000526 [/home/andrew/mozilla/dist/bin/components/libgklayout.so +0x002C8622] nsMenuFrame::HandleEvent(nsIPresContext *, nsGUIEvent *, nsEventStatus *)+0x000003DF [/home/andrew/mozilla/dist/bin/components/libgklayout.so +0x002C315F] PresShell::HandleEventInternal(nsEvent *, nsIView *, unsigned int, nsEventStatus *)+0x00000274 [/home/andrew/mozilla/dist/bin/components/libgklayout.so +0x001C4FC8] PresShell::HandleEvent(nsIView *, nsGUIEvent *, nsEventStatus *, int, int &)+0x000003B8 [/home/andrew/mozilla/dist/bin/components/libgklayout.so +0x001C4AB8] nsView::HandleEvent(nsGUIEvent *, unsigned int, nsEventStatus *, int, int &)+0x000002EA [/home/andrew/mozilla/dist/bin/components/libgkview.so +0x0001115A] nsView::HandleEvent(nsGUIEvent *, unsigned int, nsEventStatus *, int, int &)+0x0000021D [/home/andrew/mozilla/dist/bin/components/libgkview.so +0x0001108D] nsView::HandleEvent(nsGUIEvent *, unsigned int, nsEventStatus *, int, int &)+0x0000021D [/home/andrew/mozilla/dist/bin/components/libgkview.so +0x0001108D] nsView::HandleEvent(nsGUIEvent *, unsigned int, nsEventStatus *, int, int &)+0x0000021D [/home/andrew/mozilla/dist/bin/components/libgkview.so +0x0001108D] nsViewManager::DispatchEvent(nsGUIEvent *, nsEventStatus *)+0x0000091F [/home/andrew/mozilla/dist/bin/components/libgkview.so +0x0001CF4B] UNKNOWN 0x42578782 nsWidget::DispatchEvent(nsGUIEvent *, nsEventStatus &)+0x0000016D [/home/andrew/mozilla/dist/bin/components/libwidget_gtk.so +0x00047025] nsWidget::DispatchWindowEvent(nsGUIEvent *)+0x0000002E [/home/andrew/mozilla/dist/bin/components/libwidget_gtk.so +0x00046C46] nsWidget::DispatchMouseEvent(nsMouseEvent &)+0x0000004F [/home/andrew/mozilla/dist/bin/components/libwidget_gtk.so +0x000470E7] nsWidget::OnButtonReleaseSignal(_GdkEventButton *)+0x00000166 [/home/andrew/mozilla/dist/bin/components/libwidget_gtk.so +0x000483CA] nsWindow::HandleGDKEvent(_GdkEvent *)+0x000001F7 [/home/andrew/mozilla/dist/bin/components/libwidget_gtk.so +0x0004E09B] UNKNOWN 0x40996e1e handle_gdk_event(_GdkEvent *, void *)+0x00000225 [/home/andrew/mozilla/dist/bin/components/libwidget_gtk.so +0x0003EA25] UNKNOWN 0x4046cd7f UNKNOWN 0x404a0773 UNKNOWN 0x404a0d39 g_main_run+0x0000008C [/usr/lib/libglib-1.2.so.0 +0x00011EEC] gtk_main+0x000000D3 [/usr/lib/libgtk-1.2.so.0 +0x00094333] nsAppShell::Run(void)+0x00000065 [/home/andrew/mozilla/dist/bin/components/libwidget_gtk.so +0x000353A9] nsAppShellService::Run(void)+0x00000035 [/home/andrew/mozilla/dist/bin/components/libnsappshell.so +0x00042971] UNKNOWN 0x805aacd main+0x00000207 [./mozilla-bin +0x00013773] __libc_start_main+0x00000093 [/lib/i686/libc.so.6 +0x0001C627]

Thanks for trying! But what I need is the line number in nsInternetCiter.cpp that's leading to the assertion. I'll try playing with that environment variable.

I can get gdb to run ok with Mozilla, but when gdb "stops" Mozilla for a breakpoint (like nsPlaintextEditor::Rewrap), or if I do XPCOM_DEBUG_BREAK as "abort" so that Mozilla will crash instead of hang on assertion, XWindows does not give me my mouse back (I can move it, but not click). If you have any idea how I can get my mouse back, I can get you all the debugging info you want. Or if you know a way to get the Rewrap to go without using the mouse, that would work too. I figured you needed more info than XPCOM_DEBUG_BREAK=stack was giving, but I thought I'd give it a shot anyway.

That menu-freezing problem is a real pain. The only way I know of to get around it is to log in from a different console (on linux, or from another machine via the net on non-linux systems). The app is running again under gdb today, so I have a stack trace now: #0 nsDebug::Assertion ( aStr=0x400548a0 "Infinite loop: can't advance a writing iterator beyond the end of a string", aExpr=0x400547d0 "one_hop>0", aFile=0x400547a0 "../../../dist/include/string/nsStringIterator.h", aLine=330) at nsDebug.cpp:195 #1 0x400508fc in nsWritingIterator<unsigned short>::advance (this=0xbfffd5b8, n=2) at ../../../dist/include/string/nsStringIterator.h:330 #2 0x4024876a in nsAString::do_AppendFromReadable (this=0xbfffd828, aReadable=@0xbfffd708) at nsAString.cpp:362 #3 0x40248580 in nsAString::AppendFromReadable (this=0xbfffd828, aReadable=@0xbfffd708) at nsAString.cpp:328 #4 0x4004e09b in nsAString::Append (this=0xbfffd828, aReadable=@0xbfffd708) at ../../dist/include/string/nsAString.h:282 #5 0x40285071 in nsAString::operator+= (this=0xbfffd828, aReadable=@0xbfffd708) at ../../dist/include/string/nsAString.h:288 #6 0x429e67ea in nsInternetCiter::Rewrap (this=0x8a204d8, aInString=@0xbfffd848, aWrapCol=72, aFirstLineOffset=0, aRespectNewlines=1, aOutString=@0xbfffd828) at nsInternetCiter.cpp:452 #7 0x429d89ff in nsPlaintextEditor::Rewrap (this=0x89957a8, aRespectNewlines=1) at nsPlaintextEditor.cpp:1793 #8 0x42b8905d in nsEditorShell::Rewrap (this=0x89e9d00, aRespectNewlines=1) at nsEditorShell.cpp:2218

Here's what's happening. In line 392 of nsInternetCiter.cpp, we call: rv = lineBreaker->Prev(tString.get() + posInString, length - posInString, eol - posInString, &breakPt, &needMore); The first time we hit the assertion, posInString = 785, length = 10738, eol = 784. nsILineBreaker::Prev is returning NS_OK and setting breakPt to 4294967294 (which incidentally is -2 if you cast it to a signed integer, which it isn't according to the nsILineBreaker API). It looks like the line breaker is returning an improper value. What does it mean for the line breaker to return 4294967294, and how should the calling function interpret that? Assigning to intl (owners of nsLineBreaker) for answers. Feel free to assign it back to me if it turns out this is a normal condition that I should be handling (but if so, please annotate it in nsILineBreaker.h), or if there's more work I should do on my end after the line breaker part is fixed.

it looks like the third parameter in the call (eol-posInString=784-785=-1) is getting mapped to aPos, a PRUint32 (unless I'm looking at the wrong ::Prev). this is probably bad

Akkana, sometimes outStringCol+1 reaches value of aWrapCol, so eol becomes smaller than posInString what causes hang! But outStringCol+1 == aWrapCol means that we need to move to new line in outString Also what '1' stands for? Is it accounts for space after cite prefix? If so, isn't it better to add it to outStringCol right after AddCite on line 292? (Should it go back to editor?)

This seems to work. '+1' question is still open....

Yep, not the line breaker ... taking the bug back ...

Thanks very much for pointing me in the right direction! It's really better if we detect this condition right at the beginning of the inner loop, so I put a check for it there (if we're already near the end of a line, end the line and loop around again starting a new line). Patch coming, which also factors a few lines of code which were reused several times. Does it fix the problem for you? See any other potential problems with it? Re the 1 -- we're talking about the -1 in the assignment to eol on line 413 (after the new patch)? To be honest, I don't know why that's there. I don't think it's intended to account for the cite level (outStrCol should already have citeLevel added in, including the space after the citation if there is one; the new BreakLine method makes this clearer; though I wonder if we're going to miss accounting for that space on line 298? and maybe that needs a + (citeLevel ? 1 : 0) added.) The -1 should probably either be removed or (if we can figure out why it's there) a comment added explaining it. I'll go back through the CVS logs and try to see if there's a CVS comment that might explain it.

Everything seems okay now. I think we need add +(citeLevel ? 1 : 0) on line 298 (I'd prefer outStringCol = citeLevel ? citeLevel + 1 : 0; but this sooo _minor_ :-) ). I can't think of any meaning of that '1' but to account for space after cite - it wasn't accounted for in outStringCol (except single place). Also, why not to make BreakLine inline?

Comment on attachment 66556 [details] [diff] [review] Patch after Denis' and Kin's comments sr=kin@netscape.com

Folks: Kin thought that it was cleaner just to check eol after setting it, because with my previous patch, even if the next word was smaller than the slop and small enough to fit on the line, we wouldn't use it. Can someone review this? I also fixed the issues that Denis pointed out, and then verified that it still fixes the loop.

I guess no one has any objections since no one's saying anything, so I checked it in.

QA contact to Esther, it doesn't look like an intl bug.

I'm still seeing this in 0.9.8 (build 2002020406 Win32). I guess this means it only made the trunk. :-(

No, it didn't get checked into the 0.9.8 branch since no one was pushing for it (or even reviewing it). It's in the trunk, though.

*** Bug 124151 has been marked as a duplicate of this bug. ***

*** Bug 122924 has been marked as a duplicate of this bug. ***

Using build 20020322 on winxp, mac 9.1 and linux and the attached text file and scenario, this is fixed. NO freeze, text wraps while in plain text mode and sends OK. Verified.