252970 - Trunk crash [@ nsFontMetricsWin::ResolveForwards]

Status: RESOLVED FIXED

(Core Graveyard :: GFX: Win32, defect)

Description

[timeless]

FastFind
Talkback Incident ID
	
QuickSearch
Search By: Stack Signature Comments URL
Talkback Reports
Mozilla Reports Mozilla     Firefox Reports Firefox     Thunderbird Reports
Thunderbird     Camino Reports Camino
Incident ID: 404291
Stack Signature	nsFontMetricsWin::ResolveForwards b4fde65f
Product ID	MozillaTrunk
Build ID	2004071707
Trigger Time	2004-07-24 12:52:19.0
Platform	Win32
Operating System	Windows 98 4.10 build 67766446
Module	GKGFXWIN.DLL + (0000a427)
URL visited
http://www.senate.gov/legislative/LIS/roll_call_lists/roll_call_vote_cfm.cfm?congress=108&session=2&vote=00155
User Comments	I selected all of the main text, then did a view selection source.
Then it crashed.
Since Last Crash	225861 sec
Total Uptime	225861 sec
Trigger Reason	Access violation
Source File, Line No.
c:/builds/tinderbox/MozillaTrunk/WINNT_5.0_Clobber/mozilla/gfx/src/windows/nsFontMetricsWin.cpp,
line 3960
Stack Trace 	
nsFontMetricsWin::ResolveForwards 
[c:/builds/tinderbox/MozillaTrunk/WINNT_5.0_Clobber/mozilla/gfx/src/windows/nsFontMetricsWin.cpp,
line 3960]
nsRenderingContextWin::GetWidth 
[c:/builds/tinderbox/MozillaTrunk/WINNT_5.0_Clobber/mozilla/gfx/src/windows/nsRenderingContextWin.cpp,
line 1482]
nsTextFrame::PaintUnicodeText 
[c:/builds/tinderbox/MozillaTrunk/WINNT_5.0_Clobber/mozilla/layout/html/base/src/nsTextFrame.cpp,
line 2385]
nsTextFrame::Paint 
[c:/builds/tinderbox/MozillaTrunk/WINNT_5.0_Clobber/mozilla/layout/html/base/src/nsTextFrame.cpp,
line 1481]
nsContainerFrame::PaintChild 
[c:/builds/tinderbox/MozillaTrunk/WINNT_5.0_Clobber/mozilla/layout/html/base/src/nsContainerFrame.cpp,
line 306]
nsBlockFrame::PaintChild 
[c:/builds/tinderbox/MozillaTrunk/WINNT_5.0_Clobber/mozilla/layout/html/base/src/nsBlockFrame.h,
line 248]
nsBlockFrame::PaintChildren 
[c:/builds/tinderbox/MozillaTrunk/WINNT_5.0_Clobber/mozilla/layout/html/base/src/nsBlockFrame.cpp,
line 5412]
nsHTMLContainerFrame::PaintDecorationsAndChildren 
[c:/builds/tinderbox/MozillaTrunk/WINNT_5.0_Clobber/mozilla/layout/html/base/src/nsHTMLContainerFrame.cpp,
line 141]
nsBlockFrame::Paint 
[c:/builds/tinderbox/MozillaTrunk/WINNT_5.0_Clobber/mozilla/layout/html/base/src/nsBlockFrame.cpp,
line 5269]
nsContainerFrame::PaintChild 
[c:/builds/tinderbox/MozillaTrunk/WINNT_5.0_Clobber/mozilla/layout/html/base/src/nsContainerFrame.cpp,
line 306]
nsBlockFrame::PaintChild 
[c:/builds/tinderbox/MozillaTrunk/WINNT_5.0_Clobber/mozilla/layout/html/base/src/nsBlockFrame.h,
line 248]
nsBlockFrame::PaintChildren 
[c:/builds/tinderbox/MozillaTrunk/WINNT_5.0_Clobber/mozilla/layout/html/base/src/nsBlockFrame.cpp,
line 5412]
nsHTMLContainerFrame::PaintDecorationsAndChildren 
[c:/builds/tinderbox/MozillaTrunk/WINNT_5.0_Clobber/mozilla/layout/html/base/src/nsHTMLContainerFrame.cpp,
line 141]
nsBlockFrame::Paint 
[c:/builds/tinderbox/MozillaTrunk/WINNT_5.0_Clobber/mozilla/layout/html/base/src/nsBlockFrame.cpp,
line 5269]
nsContainerFrame::PaintChild 
[c:/builds/tinderbox/MozillaTrunk/WINNT_5.0_Clobber/mozilla/layout/html/base/src/nsContainerFrame.cpp,
line 306]
nsBlockFrame::PaintChild 
[c:/builds/tinderbox/MozillaTrunk/WINNT_5.0_Clobber/mozilla/layout/html/base/src/nsBlockFrame.h,
line 248]
nsBlockFrame::PaintChildren 
[c:/builds/tinderbox/MozillaTrunk/WINNT_5.0_Clobber/mozilla/layout/html/base/src/nsBlockFrame.cpp,
line 5444]
nsHTMLContainerFrame::PaintDecorationsAndChildren 
[c:/builds/tinderbox/MozillaTrunk/WINNT_5.0_Clobber/mozilla/layout/html/base/src/nsHTMLContainerFrame.cpp,
line 141]
nsBlockFrame::Paint 
[c:/builds/tinderbox/MozillaTrunk/WINNT_5.0_Clobber/mozilla/layout/html/base/src/nsBlockFrame.cpp,
line 5269]
nsContainerFrame::PaintChild 
[c:/builds/tinderbox/MozillaTrunk/WINNT_5.0_Clobber/mozilla/layout/html/base/src/nsContainerFrame.cpp,
line 306]
nsContainerFrame::PaintChildren 
[c:/builds/tinderbox/MozillaTrunk/WINNT_5.0_Clobber/mozilla/layout/html/base/src/nsContainerFrame.cpp,
line 230]
nsHTMLContainerFrame::Paint 
[c:/builds/tinderbox/MozillaTrunk/WINNT_5.0_Clobber/mozilla/layout/html/base/src/nsHTMLContainerFrame.cpp,
line 88]
CanvasFrame::Paint 
[c:/builds/tinderbox/MozillaTrunk/WINNT_5.0_Clobber/mozilla/layout/html/base/src/nsHTMLFrame.cpp,
line 393]
PresShell::Paint 
[c:/builds/tinderbox/MozillaTrunk/WINNT_5.0_Clobber/mozilla/layout/html/base/src/nsPresShell.cpp,
line 5545]
nsView::Paint 
[c:/builds/tinderbox/MozillaTrunk/WINNT_5.0_Clobber/mozilla/view/src/nsView.cpp,
line 264]
nsViewManager::RenderDisplayListElement 
[c:/builds/tinderbox/MozillaTrunk/WINNT_5.0_Clobber/mozilla/view/src/nsViewManager.cpp,
line 1390]
nsViewManager::RenderViews 
[c:/builds/tinderbox/MozillaTrunk/WINNT_5.0_Clobber/mozilla/view/src/nsViewManager.cpp,
line 1307]
nsViewManager::Refresh 
[c:/builds/tinderbox/MozillaTrunk/WINNT_5.0_Clobber/mozilla/view/src/nsViewManager.cpp,
line 873]
nsViewManager::DispatchEvent 
[c:/builds/tinderbox/MozillaTrunk/WINNT_5.0_Clobber/mozilla/view/src/nsViewManager.cpp,
line 1826]
HandleEvent 
[c:/builds/tinderbox/MozillaTrunk/WINNT_5.0_Clobber/mozilla/view/src/nsView.cpp,
line 79]
nsWindow::DispatchEvent 
[c:/builds/tinderbox/MozillaTrunk/WINNT_5.0_Clobber/mozilla/widget/src/windows/nsWindow.cpp,
line 1066]
nsWindow::DispatchWindowEvent 
[c:/builds/tinderbox/MozillaTrunk/WINNT_5.0_Clobber/mozilla/widget/src/windows/nsWindow.cpp,
line 1088]
nsWindow::OnPaint 
[c:/builds/tinderbox/MozillaTrunk/WINNT_5.0_Clobber/mozilla/widget/src/windows/nsWindow.cpp,
line 5047]
nsWindow::ProcessMessage 
[c:/builds/tinderbox/MozillaTrunk/WINNT_5.0_Clobber/mozilla/widget/src/windows/nsWindow.cpp,
line 3820]
nsWindow::WindowProc 
[c:/builds/tinderbox/MozillaTrunk/WINNT_5.0_Clobber/mozilla/widget/src/windows/nsWindow.cpp,
line 1345]
KERNEL32.DLL + 0x363b (0xbff7363b)
KERNEL32.DLL + 0x24407 (0xbff94407)

--
I tried to follow the steps:

> I generated the crash by selecting all the text in the middle column
> and then doing a "View selection source" from the context menu.

I wasn't sure what 'middle' column meant, i picked dole..lincoln (possibly also
'by senator name', and when that didn't crash, i did a select all.

but i didn't crash :(

[W] UMC: Uninitialized memory copy in
nsTextFrame::PrepareUnicodeText(nsTextTransformer&,nsAutoIndexBuffer
*,nsAutoTextBuffer *,int *,int) {2 occurrences}
        Copying 4 bytes from 0x0013d77c (4 bytes at 0x0013d77c uninitialized)
        Address 0x0013d77c points into a thread's stack 
        Address 0x0013d77c is 84 bytes past the start of local variable
'indexBuffer' in nsTextFrame::GetPointFromOffset(nsIPresContext
*,nsIRenderingContext *,int,nsPoint *)
        Thread ID: 0x1164
        Error location
            nsTextFrame::PrepareUnicodeText(nsTextTransformer&,nsAutoIndexBuffer
*,nsAutoTextBuffer *,int *,int)+0x85e
[r:\mozilla\layout\html\base\src\nstextframe.cpp:1691 ip=0x0491792b]
            nsTextFrame::GetPointFromOffset(nsIPresContext *,nsIRenderingContext
*,int,nsPoint *)+0x298 [r:\mozilla\layout\html\base\src\nstextframe.cpp:3732
ip=0x04922b12]
            nsTypedSelection::GetPointFromOffset(nsIFrame *,int,nsPoint *)+0x2b6
[r:\mozilla\content\base\src\nsselection.cpp:6961 ip=0x0460115d]
            nsTypedSelection::GetCachedFrameOffset(nsIFrame
*,int,nsPoint&)+0x18d [r:\mozilla\content\base\src\nsselection.cpp:5229
ip=0x04605412]
           
nsTypedSelection::GetSelectionRegionRectAndScrollableView(short,nsRect
*,nsIScrollableView * *)+0x48a [r:\mozilla\content\base\src\nsselection.cpp:7091
ip=0x04601683]
            nsTypedSelection::ScrollIntoView(short,int)+0x214
[r:\mozilla\content\base\src\nsselection.cpp:7460 ip=0x04602757]
            nsSelection::ScrollSelectionIntoView(short,short,int)+0x81
[r:\mozilla\content\base\src\nsselection.cpp:2819 ip=0x045f4308]
            PresShell::ScrollSelectionIntoView(short,short,int)+0x59
[r:\mozilla\layout\html\base\src\nspresshell.cpp:2594 ip=0x04455959]
            XPTC_InvokeByIndex+0x6e
[r:\mozilla\xpcom\reflect\xptcall\src\md\win32\xptcinvoke.cpp:101 ip=0x024077b7]
           
XPCWrappedNative::CallMethod(XPCCallContext&,CallMode::XPCWrappedNative)+0x122f
[r:\mozilla\js\src\xpconnect\src\xpcwrappednative.cpp:2028 ip=0x03bc9a04]
            XPC_WN_CallMethod(JSContext *,JSObject *,UINT,long *,long *)+0x1c9
[r:\mozilla\js\src\xpconnect\src\xpcwrappednativejsops.cpp:1287 ip=0x03bcfbd8]
            js_Invoke+0xefd      [r:\mozilla\js\src\jsinterp.c:1281 ip=0x03c75f12]
[W] UMR: Uninitialized memory read in
nsTextFrame::PrepareUnicodeText(nsTextTransformer&,nsAutoIndexBuffer
*,nsAutoTextBuffer *,int *,int) {2 occurrences}
        Reading 4 bytes from 0x0013d780 (4 bytes at 0x0013d780 uninitialized)
        Address 0x0013d780 points into a thread's stack 
        Address 0x0013d780 is 88 bytes past the start of local variable
'indexBuffer' in nsTextFrame::GetPointFromOffset(nsIPresContext
*,nsIRenderingContext *,int,nsPoint *)
        Thread ID: 0x1164
        Error location
            nsTextFrame::PrepareUnicodeText(nsTextTransformer&,nsAutoIndexBuffer
*,nsAutoTextBuffer *,int *,int)+0x897
[r:\mozilla\layout\html\base\src\nstextframe.cpp:1692 ip=0x04917964]
            nsTextFrame::GetPointFromOffset(nsIPresContext *,nsIRenderingContext
*,int,nsPoint *)+0x298 [r:\mozilla\layout\html\base\src\nstextframe.cpp:3732
ip=0x04922b12]
            nsTypedSelection::GetPointFromOffset(nsIFrame *,int,nsPoint *)+0x2b6
[r:\mozilla\content\base\src\nsselection.cpp:6961 ip=0x0460115d]
            nsTypedSelection::GetCachedFrameOffset(nsIFrame
*,int,nsPoint&)+0x18d [r:\mozilla\content\base\src\nsselection.cpp:5229
ip=0x04605412]
           
nsTypedSelection::GetSelectionRegionRectAndScrollableView(short,nsRect
*,nsIScrollableView * *)+0x48a [r:\mozilla\content\base\src\nsselection.cpp:7091
ip=0x04601683]
            nsTypedSelection::ScrollIntoView(short,int)+0x214
[r:\mozilla\content\base\src\nsselection.cpp:7460 ip=0x04602757]
            nsSelection::ScrollSelectionIntoView(short,short,int)+0x81
[r:\mozilla\content\base\src\nsselection.cpp:2819 ip=0x045f4308]
            PresShell::ScrollSelectionIntoView(short,short,int)+0x59
[r:\mozilla\layout\html\base\src\nspresshell.cpp:2594 ip=0x04455959]
            XPTC_InvokeByIndex+0x6e
[r:\mozilla\xpcom\reflect\xptcall\src\md\win32\xptcinvoke.cpp:101 ip=0x024077b7]
           
XPCWrappedNative::CallMethod(XPCCallContext&,CallMode::XPCWrappedNative)+0x122f
[r:\mozilla\js\src\xpconnect\src\xpcwrappednative.cpp:2028 ip=0x03bc9a04]
            XPC_WN_CallMethod(JSContext *,JSObject *,UINT,long *,long *)+0x1c9
[r:\mozilla\js\src\xpconnect\src\xpcwrappednativejsops.cpp:1287 ip=0x03bcfbd8]
            js_Invoke+0xefd      [r:\mozilla\js\src\jsinterp.c:1281 ip=0x03c75f12]
[W] UMC: Uninitialized memory copy in
nsTextFrame::PrepareUnicodeText(nsTextTransformer&,nsAutoIndexBuffer
*,nsAutoTextBuffer *,int *,int) {1 occurrence}
        Copying 4 bytes from 0x0013c730 (4 bytes at 0x0013c730 uninitialized)
        Address 0x0013c730 points into a thread's stack 
        Address 0x0013c730 is 616 bytes past the start of parameter 'indexp' in
nsTextFrame::PrepareUnicodeText(nsTextTransformer&,nsAutoIndexBuffer
*,nsAutoTextBuffer *,int *,int)
        Thread ID: 0x1164
        Error location
            nsTextFrame::PrepareUnicodeText(nsTextTransformer&,nsAutoIndexBuffer
*,nsAutoTextBuffer *,int *,int)+0x85e
[r:\mozilla\layout\html\base\src\nstextframe.cpp:1691 ip=0x0491792b]
            nsTextFrame::PaintUnicodeText(nsIPresContext
*,nsIRenderingContext&,nsStyleContext
*,TextPaintStyle::nsTextFrame&,int,int)+0x359
[r:\mozilla\layout\html\base\src\nstextframe.cpp:2245 ip=0x0491dfb5]
[W] UMR: Uninitialized memory read in
nsTextFrame::PrepareUnicodeText(nsTextTransformer&,nsAutoIndexBuffer
*,nsAutoTextBuffer *,int *,int) {1 occurrence}
        Reading 4 bytes from 0x0013c734 (4 bytes at 0x0013c734 uninitialized)
        Address 0x0013c734 points into a thread's stack 
        Address 0x0013c734 is 620 bytes past the start of parameter 'indexp' in
nsTextFrame::PrepareUnicodeText(nsTextTransformer&,nsAutoIndexBuffer
*,nsAutoTextBuffer *,int *,int)
        Thread ID: 0x1164
        Error location
            nsTextFrame::PrepareUnicodeText(nsTextTransformer&,nsAutoIndexBuffer
*,nsAutoTextBuffer *,int *,int)+0x897
[r:\mozilla\layout\html\base\src\nstextframe.cpp:1692 ip=0x04917964]
            nsTextFrame::PaintUnicodeText(nsIPresContext
*,nsIRenderingContext&,nsStyleContext
*,TextPaintStyle::nsTextFrame&,int,int)+0x359
[r:\mozilla\layout\html\base\src\nstextframe.cpp:2245 ip=0x0491dfb5]

Comment 1

[Hermann Schwab]

crashing: Mozilla/5.0 (Windows; U; Win98; en-US; rv:1.8a3) Gecko/20040724

TB407797E, TB407748K, TB407703Y

I can reproduce the crash online, and locally on a copy saved as Webpage, complete.

Scroll to  Grouped By Vote Position, and select both the YEAs ---48, and the
NAYs ---50, 
i.e. select from: Alexander (R-TN)
up to, including: Wyden (D-OR

I didn´t include the closing bracket, testing is hard, as my old system is slow
at rebooting.

Comment 2

[Hermann Schwab]

Attachment: reduced testcase, also working offline

contains simple css, don´t know if needed at all, and five tables, size 100 %

Tried to reduce table content, or delete last table, but didn´t see bug then.
Steps to reproduce: 
select from: SELECT FROM HERE to, including: SELECT TO HERE
and then View Selection Source, and enjoy Talkback coming up.

I don´t have the time to reduce it further.

Worksforme, if I delete:
<tr><td colspan="3" class="contenttext" align="center"><b>NAYs
--</b><b>50</b></td></tr>

Also wfm, when I tried to reduce the last table by deleting entries from
ARIZONA to WEST VIRGINIA.

Comment 3

[Daniel de Wildt]

WFM   Mozilla/5.0 (Windows; U; WinNT4.0; de-AT; rv:1.7) Gecko/20040618 
Crash Mozilla/5.0 (Windows; U; WinNT4.0; de-AT; rv:1.8a3) Gecko/20040724
=> OS All

TB408647W as reproduced in comment 1

Comment 4

[Daniel de Wildt]

Attachment: MSDEV assemblercode of the crash

The error occurs in line
6023A427   mov	       cx,word ptr [esi]
with ESI = 00161000 (which could be *currChar)

Comment 5

[Hermann Schwab]

Attachment: reduced testcase

removed css, <b>, <span> and one containing table. Didn´t try to shorten
tables.

Comment 6

[Andrew Hagen]

> I tried to follow the steps:
>> I generated the crash by selecting all the text in the middle column
>> and then doing a "View selection source" from the context menu.
> I wasn't sure what 'middle' column meant, i picked dole..lincoln (possibly 
> also 'by senator name', and when that didn't crash, i did a select all.
> but i didn't crash :(

I get the crash by selecting all text starting with "U.S. Senate Roll Call Votes
108th Congress - 2nd Session" (near the top) and ending with "Thomas (R-WY), Yea
Vote Summary	By Senator Name	By Vote Position	By Home State" (at the very
bottom), then doing a view selection source. Win 98, current trunk build.

Comment 7

[Hermann Schwab]

Attachment: simple testcase

removed containing table, now 3 tables only.
reduced # of lines in the state table, until bug vanished, added one line
reduced # of lines in the first table, until bug vanished, added one line

Select All, then View Selection Source.

Comment 8

[Hermann Schwab]

while producing the testcases, they always crashed at first try.
After upload as attachment, I opened the attachments to see if they are working
from bugzilla, and they did, crash at first time.
The last one however didn´t crash, then I retried the obsolete ones, they also
didn´t crash.

Got the last one crashing at third try, select manually, to get the page
scrolling, and then View Selection Source, crash at third try.

Reason for crash seems to be the colspan="3", if I remove this, I don´t get a crash.

<table valign="TOP" border="0" cellpadding="1" cellspacing="1" width="100%">
    <tbody>
	<tr>
        <td colspan="3" align="center">NAYs </td>
    </tr>
    <tr valign="top">
        <td width="33%">Akaka....


no crash using:
        <td align="center">NAYs </td>

Comment 9

[Hermann Schwab]

BuildID 2004071609 was crashing on the original website.
Select All, View Selection Source, didn´t crash, tested three times.

Manually selecting all the names from  Grouped By Vote Position:
View Selction Source was showing the selected source, then crashed after about 2
seconds.

Tested BuildID 2004071408 shortly with the SelectAll method, didn´t see a crash.

Comment 10

[Julio Belinchon]

Errors
URI : http://www.senate.gov/resources/senate_style.css

    * Line: 0 Context : added for active_legislation

      Parse Error - --> .advancedActionFailed { FONT-STYLE: italic; FONT-WEIGHT:
bold; TEXT-DECORATION: line-through; } 

Warnings
URI : http://www.senate.gov/resources/senate_style.css

    * Line : 0 font-family: You are encouraged to offer a generic family as a
last alternative

Valid CSS information

    * .contenttext {
          o font-size : 12px;
          o color : black;
          o font-family : Arial;
      }
    * BODY {
          o font-size : 12px;
          o color : black;
          o font-family : Arial;
      }
    * A {
          o color : #990000;
          o font-family : Arial;
          o text-decoration : underline;
      }
    * P {
          o margin-top : 6px;
          o margin-bottom : 1px;
      }
    * HR {
          o width : 100%;
          o color : #999999;
          o height : 1px;
      }
    * UL {
          o margin-top : 4px;
          o margin-bottom : 1px;
      }
    * TH {
          o font-weight : bold;
          o font-size : 12px;
          o margin-bottom : 1px;
          o font-family : Arial;
          o text-align : left;
      }
    * A:visited {
          o color : #666666;
          o text-decoration : underline;
      }
    * .contenttitle {
          o font-weight : bold;
          o font-size : 14px;
          o font-family : Arial;
      }
    * .contentsubtitle {
          o font-weight : bold;
          o font-size : 12px;
          o font-family : Arial;
      }
    * INPUT {
          o font-size : 10px;
          o width : 100%;
          o color : black;
          o font-family : Arial;
      }
    * .teasertext {
          o font-size : 10px;
          o color : black;
          o font-family : Arial;
      }
    * .breadcrumb {
          o font-size : 9px;
          o color : #999999;
          o font-family : Arial;
      }
    * CAPTION {
          o font-size : 10px;
          o color : black;
          o font-family : Arial;
          o text-align : center;
      }
    * .footer {
          o font-size : 8pt;
          o color : black;
          o font-family : Arial;
      }
    * .movebottom {
          o background-position : 50% 50%;
          o font-size : 10px;
      }
    * .credit {
          o font-style : italic;
      }
    * .advancedAction {
          o font-style : italic;
          o font-weight : bold;
      }
    * .advancedFailed {
          o font-weight : bold;
          o text-decoration : line-through;
      }
    * .actionFailed {
          o font-style : italic;
          o text-decoration : line-through;
      }
    * .action {
          o font-style : italic;
      }
    * .advanced {
          o font-weight : bold;
      }
    * .failed {
          o text-decoration : line-through;
      }
    * .publicLaw {
          o color : red;
      }
    * PRE {
          o font-size : 11px;
          o color : black;
          o font-family : Arial;
      }
    * TD {
          o font-size : 12px;
          o color : black;
          o font-family : Arial;
      }
    * .heading2 {
          o font-size : 11pt;
          o font-family : Arial;
          o font-weight : normal;
      }
    * .heading3 {
          o font-size : 11pt;
          o font-family : Arial;
          o font-weight : bold;
      }
    * h3 {
          o font-size : 12pt;
          o font-family : Arial;
          o font-weight : bold;
      }

This are the current problems
But Im not the webmaster of the US senate

Whith the best regards

JulioBell

Comment 11

[rbs]

WFM, Win2K, latest build.

According to the stack of comment 0, it is crashing on line 3960 (as of now)
http://lxr.mozilla.org/mozilla/source/gfx/src/windows/nsFontMetricsWin.cpp#3960

3957   // see if we can keep the same font for adjacent characters
3958   PRInt32 lastCharLen;
3959   while (currChar < lastChar) {
3960     if (IS_HIGH_SURROGATE(*currChar) && (currChar+1) < lastChar &&
IS_LOW_SURROGATE(*(currChar+1))) {
3961       nextFont = LocateFont(aDC, SURROGATE_TO_UCS4(*currChar,
*(currChar+1)), count);
3962       lastCharLen = 2;
3963     }
3964     else {
3965       nextFont = LocateFont(aDC, *currChar, count);
3966       lastCharLen = 1;
3967     }

Comment 12

[Hermann Schwab]

(In reply to comment #11)
> WFM, Win2K, latest build.

WFM Mozilla/5.0 (Windows; U; Win98; en-US; rv:1.8a3) Gecko/20040725

Win98SE, Athlon XP1600+, 512 MB RAM

It was crashing on my Win98, Celeron333, 96 MB, while I made the testcases, had
an editor open with mutliple windows, besides Mozilla.
After uploading the testcases to bugzilla, I checked them at bugzilla, they were
crashing.
After reboot, it was hard to reproduce, worked better when scrolling and
selecting manually. Maybe it depends on amount of available memory, more helps
to avoid the crash.

normally the source windows opens, and the selected text is highlighted.
In case of crash, the source window opens, text is shown, but not highlighted,
and after maybe 2 seconds Mozilla goes down, DocWatson comes up.

Comment 13

[Daniel de Wildt]

(In reply to comment #3)
> WFM   Mozilla/5.0 (Windows; U; WinNT4.0; de-AT; rv:1.7) Gecko/20040618 
> Crash Mozilla/5.0 (Windows; U; WinNT4.0; de-AT; rv:1.8a3) Gecko/20040724

WFM Mozilla/5.0 (Windows; U; Windows NT 5.0; de-AT; rv:1.8a3) Gecko/20040724

Does this only happen on Win98 and WinNT4?

Comment 14

[OstGote!]

Crashed with Mozilla 2004072708/2004072209 on WinNT4 on
http://www.mozilla.org/releases/ after view selection source. TB431245E, TB430755Z

Comment 15

[Martijn Wargers (dead)]

I experience this bug with:
http://www.bandasfilarmonicas.com/entrevista_luiscardoso.php
It happens often when I select a large portion (most of the page) of the page:
Talkback ID's: TB952781K, TB952611H and TB952498M.

Might be worth to note that this page suffers from bug 58917. Some text is not
displayed (removing some font tags make the text display again).

Comment 16

[Martijn Wargers (dead)]

> It happens often when I select a large portion (most of the page) of the page:
I meant: It happens often when I select a large portion of the page and then do
View Selection Source.

Comment 17

[Frank Wein [:mcsmurf]]

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

Comment 18

[Martijn Wargers (dead)]

Attachment: Testcase - invalid image (crash on View selection source)

When I do a View Selection Source on the placeholder text  ("The image ..
cannot be displayed... ") of an invalid image, I get a crash too (almost all of
the time).
The Talkback data of that crash seems to be similar as this bug. Talkback ID:
TB1004416H

Comment 19

[Volker Moell]

(In reply to comment #18)
> Created an attachment (id=160574)
> Testcase - invalid image (crash on View selection source)
> 
> When I do a View Selection Source on the placeholder text  ("The image ..
> cannot be displayed... ") of an invalid image, I get a crash too (almost all
> of the time).

On both 'Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.8a5) Gecko/20040930
Mnenhy/0.6.0.104' and 'Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.8a4)
Gecko/20040928 Mnenhy/0.6.0.104'  I cannot reproduce this.  I clicked on this
attachment, pressed Ctrl-A to "select all" and did a "View Selection Source" (is
this way the one you mean?) several times, and my Mozilla never crashed.  

Comment 20

[Martijn Wargers (dead)]

Sorry. I wasn't clear enough.
No, it happens when I select a part of the placeholder text (which is a bit
hard, I know) and then do View Selection Source.

Comment 21

[Volker Moell]

(In reply to comment #18)
> Created an attachment (id=160574)
> Testcase - invalid image (crash on View selection source)
> 
> When I do a View Selection Source on the placeholder text  ("The image ..
> cannot be displayed... ") of an invalid image, I get a crash too (almost all of
> the time).

I still cannot reproduce this behaviour on Linux (Mozilla/5.0 (X11; U; Linux
i686; en-US; rv:1.8a5) Gecko/20040930 Mnenhy/0.6.0.104).

Comment 22

[Jungshik Shin]

(In reply to comment #21)

> I still cannot reproduce this behaviour on Linux

You're not supposed to reproduce this on Linux. See the stack uploaded here.
It's happening in nsFontMetricsWin.cpp (see comment #11)

Comment 23

[Volker Moell]

(In reply to comment #22)
> You're not supposed to reproduce this on Linux. See the stack uploaded here.
> It's happening in nsFontMetricsWin.cpp (see comment #11)

I tested it because "my own" bug #261641 was marked as a duplicate of this bug a
few days ago.  So it's not sure that this bug #252970 and bug #261641 really are
duplicate?

Comment 24

[Daniel de Wildt]

Filled TB1064197Q happend with the URL of bug 252970 but with an other part of
the source.
The stack seems nothing to do with windows specific source code. See also stacks
of the TBs in comment 15. Only one has nsFontMetricsWin::ResolveForwards as the
crash point. I guess that all crashes are the same bug and the real reason for
the crashes is somewhere else.

Comment 25

[Daniel de Wildt]

Sorry, I used the URL of bug 261641.
http://wunschliste.de/index.pl?vote&r=00&abc=B
Select a large part of the middle column. The selection should end at the end of
a line.

Comment 26

[Daniel de Wildt]

Some TBs after a source view of the url from bug 261641:
TB1064197Q: 
@nsScriptSecurityManager::GetScriptPrincipal

TB1064385W, TB1064660H, TB1068188E, TB1068233M, TB1068436K:
@nsFontMetricsWin::ResolveForwards

Maybe TBs from other OS could help.

Comment 27

[Hermann Schwab]

wfm Mozilla/5.0 (Windows; U; Win98; en-US; rv:1.8a5) Gecko/20041022

also tested working with yesterdays nightly, which was crashing on another 'View
Selection Source' bug.

Comment 28

[François Gagné]

still crashing with nightly build 2004102206 on the "Testcase - invalid image
(crash on View selection source)" test case when selecting the last dot and
doing a "view selection source".

Comment 29

[Hermann Schwab]

still crashing: Mozilla/5.0 (Windows; U; Win98; en-US; rv:1.8a5) Gecko/20041022

URL from this bug is wfm, but I used URL from bug 130900

http://www.area450.com/hacks/regionhack.htm

Just did 'Select All', 'View Selection Source', -> crash, reproducable.

Stack Signature: nsFontMetricsWin::ResolveForwards 3aaffa00
http://talkback-public.mozilla.org/talkback/fastfind.jsp?search=2&type=iid&id=TB1463279Y


54 crashes found, Stack Signature contains 'nsfontmetricswin::resolveforwards'
http://talkback-public.mozilla.org/talkback/fastfind.jsp?search=1&searchby=stacksig&match=contains&searchfor=+nsFontMetricsWin%3A%3AResolveForwards&vendor=All&product=All&platform=All&buildid=&sdate=&stime=&edate=&etime=&sortby=bbid

Comment 30

[Jungshik Shin]

This might, indeed, be an XP bug. (i.e. I may have been wrong in comment #22) I
suspect that layout passes a bogus  string length to Gfx in some cases. That is,
in ResolveForward, 'currChar < lastChar' is not a guarantee that we're within
the range any more...  rbs, what do you think?  bug 261641 comment #0 has the
following:

> The bug did not appear on self-build CVS of 20040529. It is present on every
> later version.

Comment 31

[Frank Wein [:mcsmurf]]

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

Comment 32

[François Gagné]

> This might, indeed, be an XP bug. 

from comment #29 : Mozilla/5.0 (Windows; U; Win98; en-US; rv:1.8a5)

so this bug is affecting win9x and winnt5.x

Comment 33

[timeless]

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

Comment 34

[bgp]

(In reply to comment #33)
> *** Bug 273261 has been marked as a duplicate of this bug. ***

The bug you marked as duplicate affects Linux too, so this bug shouldn't be
Windows only OR it is not a duplicate.

Comment 35

[Jay Patel [:jay]]

This is a topcrasher with recent MozillaTrunk builds.  A few Talkback comments
also mention that the testcase in bug 213408 is causing this crash (or at least
one with the same stack trace)...so there might be clues there.

Marking topcrash+ since we have a reproducible testcase.

Comment 36

[rbs]

Re: Comment #30

Indeed jshin, some problems elswehere are causing 'currChar < lastChar' to
become meaningless. Comment 35 which mentions bug 213408 now allows to see the
source. It appears to be another upshot of those &shy problems (like bug 267669
too).

Comment 37

[Olivier Cahagne]

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

Comment 38

[Jungshik Shin]

Talkbacks with ResolveForwards as crash point have been coming (2005-02-03
nightly is the latest),but I couldn't reproduce it with my trunk debug build on
Win 2k. I tried all the test cases mentioned here. This bug is rather elusive.
There may be something that trigger this bug only in optimized builds.....

Comment 39

[Brendan Eich [:brendan]]

Any idea when this appeared, so we can hypothesize a regression and check bonsai?

/be

Comment 40

[Hermann Schwab]

(In reply to comment #39)
> Any idea when this appeared, so we can hypothesize a regression and check bonsai?
> 
> /be

In comment #9 I saw a 2 day regression timespan, and I´ve made testcases for
this bug, but apparently they were crashing because the making of testcases was
corrupting my memory. They were crashing, when after upload I checked per
download, but didn´t crash after reboot.
I retried some times to reproduce the crash, didn´t succeed.

Comment 41

[Brian Ryner (not reading)]

I tested this with today's Firefox nightly on Windows XP SP2, Windows 98, and
Windows 2000 and did not crash.  I also ran under purify on XP and didn't see
anything unusual in the font code.

Comment 42

[Martijn Wargers (dead)]

I can still crash 100% reproducable with "Testcase - invalid image (crash on
View selection source)". Just select a part of the text on the invalid image and
do view selection source.
This does not crash in 2004-08-01 07:08:00 Firefox trunk build.
This does crash in 2004-08-02 08:02:00 Firefox trunk build.
http://bonsai.mozilla.org/cvsquery.cgi?treeid=default&module=all&branch=HEAD&branchtype=match&dir=&file=&filetype=match&who=&whotype=match&sortby=Date&hours=2&date=explicit&mindate=2004-08-01+07%3A08%3A00&maxdate=2004-08-02+08%3A08%3A00&cvsroot=%2Fcvsroot
I know this is not consistent with other obeservations, but the stack signature
of this kind of crash is the same as what this bug has.

Comment 43

[Hermann Schwab]

identical crashes Firefox/Mozilla trunk with current nightlies on testcase
'invalid image':
http://talkback-public.mozilla.org/talkback/fastfind.jsp?search=2&type=iid&id=TB3658380Q
http://talkback-public.mozilla.org/talkback/fastfind.jsp?search=2&type=iid&id=TB3658195X

searching this stack signature gives about 32 Talkbacks, about half of them
trunk, and a half thereof Mozilla trunk.
http://talkback-public.mozilla.org/talkback/fastfind.jsp?search=1&searchby=stacksig&match=contains&searchfor=+nsFontMetricsWin%3A%3AResolveForwards&vendor=All&product=All&platform=All&buildid=&sdate=&stime=&edate=&etime=&sortby=bbid

Other testcases and URLs don´t show the bug anymore.
Today I retried 1.8a3: 2004071903 and got a crash at third try at the URL, and a
crash after rebooting, and only loading the bug and the testcase at second try.

Comment #7  2004-07-25 I made three testcases, multiply tested crashing while
made, and crashing on download after uploading to bugzilla. After reboot, I
couldn´t reproduce the testcases.

So it seems something has been fixed between 1.8a3: 2004071903 and 2004-07-25

Comment #8 found reason for a reproducable crash having colspan="3"
Comment #9 found BuildID 2004071408 not crashing, 2004071609 crashing  on URL

I didn´t find BuildIDs in following comments, seems the crashes stopped 2004-07-25.

As comment 42 states, crashes for testcase 'invalid image' started between 
2004-08-01 07:08 and 2004-08-02 08:02 Firefox trunk, so that may be another
issue different from that causing the original bug.

Comment #29 2004-10-22 crashed on testcase of another bug giving same stack
signature, but that build didn´t crash using current nightlies at any of the
URLs mentioned here.

To 'View Selection Source', you must select something before.
I can´t start selecting *in* the message 'The image
“https://bugzilla.mozilla.org/attachment.cgi?id=160574” cannot be displayed,
because it contains errors.', I only can start the selection from the outside of
the string, doesn´t matter if left to right or right to left. 

Comment 44

[Asa Dotzler [:asa]]

pulling from the blocking list since this may not be the problem it was. 

Comment 45

[Martijn Wargers (dead)]

Attachment: Testcase3

With the <isindex> tag it is also crashing with this stack on view selection
source. And this time it is easily selectable. This also crashes 100%
reproducable for me.

Comment 46

[Daniel de Wildt]

Some of the TB stacktraces with crash in nsFontMetricsWin::ResolveForwards runs
through nsTextFrame::GetPointFromOffset. Maybe someone could put some attention on
http://bonsai.mozilla.org/cvsblame.cgi?file=/mozilla/layout/generic/nsTextFrame.cpp&mark=3901,3906&rev=1.494#3894
The first line contains an assignment and not only comparisons.

Comment 47

[timeless]

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

Comment 48

[rbs]

I still cannot reproduce this bug at all. No even a single crash so far. Can
someone setup a JavaScript script that triggers the crash?

Comment 49

[alexander :surkov (:asurkov)]

Try a test https://bugzilla.mozilla.org/attachment.cgi?id=171007

Comment 50

[rbs]

I get this assertion (which doesn't involve the font code), and there is no crash.

###!!! ASSERTION: invalid offset passed to GetPointFromOffset: '0', file d:/Mozi
lla/tip/mozilla/layout/generic/nsTextFrame.cpp, line 3964

Comment 51

[Martijn Wargers (dead)]

The latest nightly trunk builds crash for me on the mentioned testcases.
My very recent MingW debug Mozilla build however, doesn't crash.

Comment 52

[Hermann Schwab]

WIN98SE testcase3 view selection source on something like 'a searchable index.
Enter search'
http://talkback-public.mozilla.org/talkback/fastfind.jsp?search=2&type=iid&id=TB5027858Z

nsFontMetricsWin::ResolveForwards 
[c:/builds/tinderbox/MozillaTrunk/WINNT_5.0_Clobber/mozilla/gfx/src/windows/nsFontMetricsWin.cpp,
line 3872] etc...

got another crash TB5027893W don´t think is related.

Comment 53

[Karsten Düsterloh]

I can reproduce the crash for the invalid image testcase on WinXP with the
Mozilla nightly 2005-04-11 - and that's a MSVC build.
I cannot reproduce that with my MinGW Mozilla debug build, though.

I'll test that with a MSVC Mozilla debug build on a Win2k machine tonight.

Comment 54

[Karsten Düsterloh]

I cannot reproduce this with my MSVC6 Mozilla debug build of 2005-04-09 on my
Win2k machine, for all three testcases.

Comment 55

[Chris]

cannot reproduce any testcase on Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US;
rv:1.8b2) Gecko/20050604 Firefox/1.0+ ID:2005060406

windows 2000sp4

Comment 56

[Hermann Schwab]

crash Mozilla/5.0 (Windows; U; Win98; en-US; rv:1.8b2) Gecko/20050605
TB6411657X
http://talkback-public.mozilla.org/talkback/fastfind.jsp?search=2&type=iid&id=TB6411657X

Steps to repeat:
1. Load testcase 3: https://bugzilla.mozilla.org/attachment.cgi?id=175000

You'll see:

This is a searchable index. Enter search keywords:[Textarea]
<hr>
Select part of the text of the text here above and then do "View Selection
Source".This should not crash Mozilla.

2. Select something in the line preceding the [textarea],
let's say select 'searchable'

3. Right click -> View Selection Source -> crash

You won't crash if you select something following the textarea.
I didn´t test other testcases, as I remember they never crashed starting with
comment #9, ages ago, and I restested all of them some weeks ago.
Seems testcase #3 is the only one still crashing. testing that one first time it
didn´t crash, as I selected text below the textbox.

Comment 57

[Hermann Schwab]

Attachment: testcase 4

I made testcase 4 from the code of testcase 3 by removing all text, so the text
you can select is the text which will crash.

<html>
<head><title>Select some text and right-click "View Selection
Source"</title></head>
<body><isindex></body>
</html>



obsolete, as they don't crash anymore: 
Attachment 154309 [details]: simple testcase
Attachment 160574 [details]: Testcase - invalid image (crash on View selection source)

Comment 58

[Hermann Schwab]

Comment on attachment 160574 [details]
Testcase - invalid image (crash on View selection source)

It's not easy to select text here, but if you succeed, you'll crash on 'view
selection source'

Comment 59

[Hermann Schwab]

Both testcases attachment 160574 [details] 'invalid image' and testcase 4 attachment
185411 [details] <body><isindex></body> don´t contain text in the HTML source, but show
text provided by Mozilla.

That text can´t be selected using 'Select All' shown on right-click, but can be
selected normally with left-click. 
'Select All' shouldn't be available, when it can't be used besides destroying
the   selection done with the mouse, i.e. 'select All' here acts only as
'deselect All'
Maybe that's bug 294383


Steps to repeat crashes:

1. load testcase 'invalid image' or testcase 4:
https://bugzilla.mozilla.org/attachment.cgi?id=160574
https://bugzilla.mozilla.org/attachment.cgi?id=185411

2. select some text in the testcase.
   I had to try multiple times to get text selected on the invalid image.

3. If you don´t see a selection, return to step 2
   Right-Click and click 'View Selection Source'

Comment 60

[rbs]

Still no crash for me. I am (and have been) using a debug build all along.

>  I had to try multiple times to get text selected on the invalid image.

It is not difficult if you select backwards from the end of the line.

Comment 61

[Asa Dotzler [:asa]]

->jshin. 

jshin, can you help us with this for 1.8b3?

Comment 62

[Jungshik Shin]

I can't reproduce it, either. Herman, can you give me all the details of your
font setting when you get crash? 

Comment 63

[Caleb]

Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8b2) Gecko/20050614
Firefox/1.0+ ID:2005061421

I can reproduce the crashes on Testcase 3 and Testcase 4.

Just select the "This is a searchable index." text, and right click > View
Selection Source and Firefox crashes.

Comment 64

[Hermann Schwab]

Attachment: info requested in comment 62

(In reply to comment #62)
> I can't reproduce it, either. Herman, can you give me all the details of your

> font setting when you get crash? 

excerpts from prefs.js, all.js, and complete listing of the windows fonts
directory. 

identical Talkbacks on different testcases:
Mozilla/5.0 (Windows; U; Win98; en-US; rv:1.8b2) Gecko/20050616
http://talkback-public.mozilla.org/talkback/fastfind.jsp?search=2&type=iid&id=TB6732972H

http://talkback-public.mozilla.org/talkback/fastfind.jsp?search=2&type=iid&id=TB6733192W


If you want I can attach about 9 screenshots of about:config with filter
'font', size will be about 12 kb for each one. 
I also could make screenshots of preferences, if wamted. Should I zip the
screenshots to one archive?

current settings:
View -> Character Encoding -> AutoDetect -> Universal
View -> Character Encoding -> Western (ISO-8859-1)

Comment 65

[Hermann Schwab]

Attachment: Screenshot Preferences->Appearence->Fonts

I changed the setting to Autodetect: OFF and still get crashes.

Testcase 4 I selected 'searchable index' and didn´t crash on
ViewSelectionSource.
I closed the source window and retried 5 times, without touching the selection,
all went well. Then I changed the selection, and crashed on
ViewSelectionSource.

Comment 66

[chris hofmann]

so jshin, does changing the setting to Autodetect: OFF make it reproducable for you?

Comment 67

[Tracy Walker [:tracy]]

With a fresh/default profile I crashed using Deer Park 2005-06-21-07-trunk on
Windows XP sp2 following calebs simple steps in comment #63 for test cases 3 and 4.

note: Using File | View Source doesn't crash those test cases.  You must use the
context menu for View Selection Source.

TalkbackID : TB6867422Q

Comment 68

[Jungshik Shin]

I still can't reproduce the bug. Just in case, can you check  the value of

HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\LanguagePack]
  SURROGATE

in  the Windows registry? It shouldn't make a difference, but who knows? 
If it's not 2,change it to 2 and see if mozilla/firefox still crashes.

(http://www.i18nguy.com/surrogates.html)

Comment 69

[Caleb]

(In reply to comment #68)
> I still can't reproduce the bug. Just in case, can you check  the value of
> 
> HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\LanguagePack]
>   SURROGATE
> 
> in  the Windows registry? It shouldn't make a difference, but who knows? 
> If it's not 2,change it to 2 and see if mozilla/firefox still crashes.
> 
> (http://www.i18nguy.com/surrogates.html)

I don't even have that key. (SURROGATE)

Comment 70

[Jungshik Shin]

(In reply to comment #69)
> (In reply to comment #68)
> > HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\LanguagePack]
> >   SURROGATE

> I don't even have that key. (SURROGATE)

That's normal. What I meant (I was not clear ) was you need to create it and set
to 2. Anyway,never mind. I can reproduce the crash the latest nightly I
downloaded from ftp.mozillla.org, but my debug build never crashes (I made sure
that files in my tree with functions in the stack backtrace are identical
to those in the trunk).  Perhaps, I have to build an optimized build and see
what I can do.

Comment 71

[Jungshik Shin]

I wanted to build a optimized build with symbols, but the compilation keeps
failing when it comes to building gklayout.dll with an exception from 'cvpack'

http://groups-beta.google.com/group/netscape.public.mozilla.builds/browse_thread/thread/736f3b8791ed959b/dbebfc5d57c92f37?q=cvpack+firefox&rnum=1&hl=en#dbebfc5d57c92f37

It appears that older versions of cvpack (before VC++ 6.0) had some problems
(there are a lot of news postings and web pages about it), but I can't find any
solution to my problem (VC++ 6.0 + SP5).  There are a couple of questions about
the issue on some lists, but no answer. I'll keep looking. Ahah, perhaps, I have
to switch my 'ANSI' locale to English from Korean and see if it helps (in the
past, I was able to work around apparent 'VC-related' bugs that way)

Comment 72

[Jungshik Shin]

(In reply to comment #71)
> I wanted to build a optimized build with symbols, but the compilation keeps
> failing ..... I have
> to switch my 'ANSI' locale to English from Korean and see if it helps 

Unfortunately, this didn't help. Is there anyone who successfully built an
optimzed build of firefox with debug symbols (it's pretty certain that debug
builds are fine while optimized build crash so that we need to debug with an
optimized build)? I tried to debug with assembly, but my knowlege of x86
assembly is minimal...

Comment 73

[Benjamin Smedberg]

Try --enable-optimize --disable-debug --enable-debugger-info-modules=all

Comment 74

[Mike Connor [:mconnor]]

I can reproduce with the suggested config from bsmedberg, what am I looking for?

Comment 75

[Bernard Alleysson]

fwiw, on Windows, I use 
--enable-optimize
--disable-debug
and I define the env variable "set MOZ_DEBUG_SYMBOLS=1" before building

Comment 76

[Chris Beard]

closing down for 1.8b3, let's try and get this in for 1.8b4

Comment 77

[Jungshik Shin]

'cvpack' still fails with what's suggested in comment #73. I'll try what's
suggested in comment #75. 

re: comment #74
Can you check whether the value (aLength) passed down from
layout/html/base/src/nsTextFrame.cpp (nsTextFrame::PaintUnicodeText) is 'valid'? 

3857 nsFontMetricsWin::ResolveForwards(HDC                  aDC,
3858                                   const PRUnichar*     aString,
3859                                   PRUint32             aLength,
3860                                   nsFontSwitchCallback aFunc, 
3861                                   void*                aData)

In ResolveForwards, we do all the right checks, but still |currChar| (ESI in
attachment 154298 [details] (comment #4))  points to an 'invalid address' location.

Comment 78

[Jungshik Shin]

In light of comment #46, wall-painting-patch (attachment 188695 [details] [diff] [review] to bug 300122)
may prevent some (not all) crashes dealt with here. We may be able to come up
with a similar wall-painting patch for other cases, but we'd better track down
the root cause.

Comment 79

[rbs]

Attachment: Patch for view-selection-source

I have finally been able to reproduce this in a debug build.  To do so, just
comment out the conditional debug "memset" that are sprinkled in the |struct
nsAutoIndexBuffer|.

It turns out that this bug comes all the way from the content model. There are
some operations that lead to gibberish in textnodes (which are later fed to the
font code).

One particular operation that triggers this crash is when inserting a child
textnode to a leaf element such as <index>. In principle, this should fail, but
it doesn't. [Since the content mode does allow anonymous nodes, it is not clear
if it should indeed fail. But from the DOM functions, it can be argued that
<isndex>.insertBefore() should fail rather than insert gibberish. Still, layout
shouldn't crash either...]

I am attaching a simple patch to protect View-Selection-Source for the common
cases. A comprehensive fix would be to prevent the gibberish character data.

Comment 80

[Boris Zbarsky [:bzbarsky]]

> One particular operation that triggers this crash is when inserting a child
> textnode to a leaf element such as <index>.

There is no such thing as a leaf element in the DOM (consider XML, where the
concept really just doesn't exist for a non-validating parser)....

Do you have a testcase for this "gibberish character data" thing?  That really
should not be happening.

Comment 81

[Boris Zbarsky [:bzbarsky]]

Comment on attachment 189507 [details] [diff] [review]
Patch for view-selection-source

I'm not really following what this patch is doing...

Comment 82

[rbs]

It is a "diff -w". It puts an if () {...} around a big chunk of code, see:
http://lxr.mozilla.org/mozilla/source/xpfe/browser/resources/content/viewPartia
lSource.js#126

Try View Selection Source on testcase 4 to see what I mean. It gives a 
childless <isindex>. For such cases, the selection can't be re-mapped because 
the original selection is within anonymous nodes. So the |if| skips the 
attempt to re-map since it will fail anyway.

To see the corrupted text nodes (gibberish) requires disabling the "memset" 
that I indicated, and then dumping the content model (see also bug 300122). I 
am curious about it but had to leave the (long) debugging at that point. In 
the mean time, let's go with this simple patch to cut the obvious cases.

Comment 83

[rbs]

...to be clear, albeit it should now be obvious, the second |if| stops the 
|drawSelection| function from being attached as a listener because if no 
selection has been re-mapped, then there will be nothing to draw too.

Comment 84

[Martijn Wargers (dead)]

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

Comment 85

[Boris Zbarsky [:bzbarsky]]

Sorry, I didn't realize I wasn't cced on this bug.  :(

> the selection can't be re-mapped

Meaning what?  That it doesn't correspond to non-anonymous DOM?  What does view
selection source show with your change?

> In the mean time, let's go with this simple patch to cut the obvious cases.

I'm sorry, but if we're ending up with garbage in our content model, we should
fix that (blocking 1.8b4+ and all), not just paper over it in the UI.

Comment 86

[Boris Zbarsky [:bzbarsky]]

> To see the corrupted text nodes (gibberish) requires disabling the "memset" 
> that I indicated, and then dumping the content model

Doing this in the layout debugger, I assume?  Does doing that on "Testcase 4"
show the problem?

Comment 87

[Boris Zbarsky [:bzbarsky]]

So my problem is that status whiteboard claims this is a major tbird crasher. 
So unless tbird has "view selection source", there's something else going on....

Comment 88

[rbs]

The patch is not meant to fix the root cause of the the bug. Until then, the bug
isn't fixed. But I have now gathered per you comment that it is not unusual for
<isindex> to get children. It remais to identify if the root cause is something
related to munging strings or DOM ranges. It is also seem more and more likely
that it might just be a text transform bug, in which case it will explain bug
301104 too. (The dump was by brute force printfs...)

---------
As for the suggested |if|-patch, it is something that I would add today if I
were to re-write View Selection Source. Basically, what happens is this: for
display purposes, <isindex> "mutates" itself in the content model as:

<isindex>
 - <anonymous hr/> 
 - <anonymous text> 
     This is a searchable index. Enter searh keywords:
   </anonymous text>
 - <anonymous input field/>
 - <anonymous hr/> 

1. Then, the user selects a part of the anonymous text, and clicks on View
Selection Source. 
2. View Selection Source identifies that the selected text comes from <isindex>
and try to do <isindex>.cloneNode(true/*aDeep*/) so that it can re-map the
selection to its underlying markup. But the cloning doesn't go deep because what
is inside is anonymous, with no associated markup. Hence it returns a childless
<isindex/>.
3. Then, comes the ensuing munging to attempt to re-map the selection into that
cloned, childless <isindex/>. And it is this munging that creates the
circumstances fitted for the crash (for View Selection Source).

So the suggested |if|-patch simply skips the munging, which is unnecessary
anyway. View Selection Source simply shows "<isindex>"--as you currently see in
debug builds. As I indicated, I would add that |if| today because of this added
understanding/scenario. It doesn't change anything, but avoid creating the
circumstances of the crash.

The same situation happens with broken images because <img> "mutates" itself in
an anonymous placeholder text to display the message ("The image ... cannot be
displayed... ").

I don't understand why it is a tbird crasher, either. There aren't any dups from
tbird. Neither was tbird mentioned when the bug was originally marked as
topcrash+ in comment 35.

Comment 89

[Boris Zbarsky [:bzbarsky]]

Comment on attachment 189507 [details] [diff] [review]
Patch for view-selection-source

OK, r+sr=bzbarsky, but we need to figure out the real issue too...

Comment 90

[rbs]

Comment on attachment 189507 [details] [diff] [review]
Patch for view-selection-source

Asking approval for 1.8b4. The patch doesn't fix the real crash. It instead
prevents us from triggering a codepath (in the case of the frequently used View
Selection Source) that leads to the crash. Hopefully, it will give us a little
breathing space until we find the real root cause of the crash in layout.

Comment 91

[rbs]

Attachment: fix the root cause

Comment 92

[rbs]

Attachment: fix the root cause

bz, there it goes. Happy now?

Comment 93

[rbs]

Comment on attachment 190679 [details] [diff] [review]
fix the root cause

Not sure why it submitted twice. (For those who are curious, the crash came
from outdated pointers.)

Comment 94

[Caleb]

Comment on attachment 189507 [details] [diff] [review]
Patch for view-selection-source

This patch has been checked in.

When I right click > View Selection Source on testcase 3 and 4, I get
"<isindex>" in the source window instead of some actual text, is this designed
behaviour?

Comment 95

[Hermann Schwab]

wfm Mozilla/5.0 (Windows; U; Win98; en-US; rv:1.8b4) Gecko/20050727 SeaMonkey/1.0a

As the workaround 'Patch for view-selection-source' got checked in, and the real
 patch to 'fix the root cause' is still waiting for review, that bug is still
open, I assume.


(In reply to comment #94)
> When I right click > View Selection Source on testcase 3 and 4, I get
> "<isindex>" in the source window instead of some actual text, is this designed
> behaviour?
 
Complete source of Attachment 185411 [details] (testcase 4):

<html>
<head><title>Select some text and right-click "View Selection Source"</title></head>
<body><isindex></body>
</html>

so there is no more to be seen in the <body> than <isindex>.

Comment 96

[Boris Zbarsky [:bzbarsky]]

Comment on attachment 190681 [details] [diff] [review]
fix the root cause

So... why does this help?  That is, do we end up with a reflow _while_
scrolling or something?

Comment 97

[rbs]

Sort of. It is the other way around. Reflows are made to terminate before we
effectively begin to scroll. 

The scroll under consideration, |nsTypedSelection::ScrollIntoView|, is specific
to the selection. It doesn't even ultimately call the
|PresShell::ScrollFrameIntoView| -- which is what you seemed to have been
thinking of.

Since the selection usually wants to scroll at a character within the frame, it
has its own self-contained code. It works out where it wants to scroll and calls
APIs on the scrollable view directly, much like nsPresShell::GotoAnchor() for
example, which already calls FlushPendingNotifications() and takes no chances.

But the bug is somewhere else--a little earlier to the actual scroll. The crux
of the matter is this: the selection wants to scroll at a character within the
frame. Hence, it has to measure the text, using content offsets that are
supposed to have been set by the most recent reflow. The crash comes from the
fact that the frame under consideration is dirty (it has been dirtied by the
munge in the case of View Selection Source). Its content offsets are now
outdated and point to potential garbage. It must be reflowed before we dare to
call nsTextFrame::GetPointFromOffset().

In fact, the munging effectively triggers some CharacterDataChanged()
notifications, but their corresponding reflows are agressively optimized out
these days. As the selection code has no idea that these have been deferred, it
crashes when it attempts to find out where to scroll.

[This king of elusive bug might manifest itself no just with
GetPointFromOffset(). There are other APIs that also assume that the frame is
ready. It wouldn't be a bad thing to sprinkle them with
NS_ASSERTION((mState & NS_FRAME_IS_DIRTY) == 0, "clean up your frame")...]

Comment 98

[Boris Zbarsky [:bzbarsky]]

Comment on attachment 190681 [details] [diff] [review]
fix the root cause

I see.	Put the first half of the third paragraph of comment 97 in this
code-level comment, please?  And please file a followup bugs on adding the
asserts you mention.

Comment 99

[rbs]

Comment on attachment 190681 [details] [diff] [review]
fix the root cause

Asking a=1.8b4 on this top crasher which is now well understood.

Comment 100

[rbs]

Checked in. Filed bug 302728 for follow-up.