Closed Bug 73291 Opened 23 years ago Closed 23 years ago

invalid memory reference shortening text element in onload handler

Categories

(Core :: Layout, defect)

Product:
Core
Component:
Layout
Platform:
x86
Windows 2000
Type:
defect
Priority:
Not set
Severity:
major

Tracking

()

Status:
VERIFIED FIXED
Milestone:
mozilla0.9.1

People

(Reporter: danm.moz, Assigned: waterson)

References

Details

(Keywords: crash)

Attachments

(2 files)

JS test case that causes crash in nsTextFrame::PaintAsciiText()
813 bytes, text/html
Details
fix along the lines of what kin proposed
1.29 KB, patch
Details | Diff | Splinter Review 
This might be a fairly esoteric bug, but it's potentially serious.
  Experimentation leads me to believe the problem happens when loading an html 
page containing script that shortens the contents of a text element in the 
onload handler. Test case below. (I think the test could be shortened, but 
for some reason this arrangement gives more reliably visible results.)
  The Reload button seems to exacerbate the problem. Or maybe it's required to 
see it. Generally, it looks like it's drawing a long string of random memory 
characters, and then painting over most of that with the real text ("true" or 
"false"), leaving a few garbage chars on the right.
  I've done this about 100 times (not because I was bored) and generally 
suffered nothing worse than garbage display. Once though, it crashed in 
nsTextFrame::PaintAsciiText. The contents were correct (|text| pointed to a 
0-terminated ascii string "true" (or "false", whatever)) but nsTextFrame's 
member variable |mContentLength| had a value that happened to be equal to the 
length of the original text contents of that element (40 in the example).
  Seems like memory is being scanned off the end of the allocation because of an 
unadjusted length value.

<html><head><script>
  var status = false;
  function toggleStatus() {
    status = !status;
    showStatus();
  }
  function showStatus() {
    var node = document.getElementById("statusdiv");
    node.firstChild.data = status ? "true" : "false";
  }
</script></head>
<body onload="showStatus()">
<form>
  <input type=button value="toggle status" onclick="toggleStatus()">
</form>
<br>
status is
<div style="display:inline" id="statusdiv">40 characters of text is a good 
start...</div>
</body></html>
Shiva, does nsTextFrame::PaintAsciiText show up in Talkback logs?
Keywords: crash
This crash seems to have started appearing end of february(I need to verify) in
N601 release build. I am not seeing them in Trunk builds or M08 builds.  I have 
attached stacktrace and the list of user comments to reproduce the problem.

Shiva


nsTextFrame::PaintAsciiText   22                          
     First BBID : 
http://climate/reports/stackcommentemail.cfm?dynamicBBID=26970623
     Last BBID  : 
http://climate/reports/stackcommentemail.cfm?dynamicBBID=27095261
     Min Runtime :566
     Max Runtime :1070491
     Min seconds since last crash :312
     Max seconds since last crash :586633
     First Appearance Date : 2001-02-26
     Lastest Appearance Date : 2001-02-28
     First Build ID : 2001013114
     Lastest Build ID : 2001013114

Stack Trace: 

         nsTextFrame::PaintAsciiText    
[d:\builds\6.01\mozilla\layout\html\base\src\nsTextFrame.cpp  line 2542] 
         nsTextFrame::Paint     
[d:\builds\6.01\mozilla\layout\html\base\src\nsTextFrame.cpp  line 1260] 
         nsContainerFrame::PaintChild   
[d:\builds\6.01\mozilla\layout\html\base\src\nsContainerFrame.cpp  line 211] 
         nsBlockFrame::PaintChildren    
[d:\builds\6.01\mozilla\layout\html\base\src\nsBlockFrame.cpp  line 6419] 
         nsBlockFrame::Paint    
[d:\builds\6.01\mozilla\layout\html\base\src\nsBlockFrame.cpp  line 6297] 
         nsBoxFrame::PaintChild 
[d:\builds\6.01\mozilla\layout\xul\base\src\nsBoxFrame.cpp  line 1403] 
         nsBoxFrame::PaintChildren      
[d:\builds\6.01\mozilla\layout\xul\base\src\nsBoxFrame.cpp  line 1539] 
         nsBoxFrame::Paint      
[d:\builds\6.01\mozilla\layout\xul\base\src\nsBoxFrame.cpp  line 1357] 
         nsBoxFrame::PaintChild 
[d:\builds\6.01\mozilla\layout\xul\base\src\nsBoxFrame.cpp  line 1403] 
         nsBoxFrame::PaintChildren      
[d:\builds\6.01\mozilla\layout\xul\base\src\nsBoxFrame.cpp  line 1539] 
         nsBoxFrame::Paint      
[d:\builds\6.01\mozilla\layout\xul\base\src\nsBoxFrame.cpp  line 1357] 
         nsBoxFrame::PaintChild 
[d:\builds\6.01\mozilla\layout\xul\base\src\nsBoxFrame.cpp  line 1403] 
         nsBoxFrame::PaintChildren      
[d:\builds\6.01\mozilla\layout\xul\base\src\nsBoxFrame.cpp  line 1539] 
         nsBoxFrame::Paint      
[d:\builds\6.01\mozilla\layout\xul\base\src\nsBoxFrame.cpp  line 1357] 
         nsBoxFrame::PaintChild 
[d:\builds\6.01\mozilla\layout\xul\base\src\nsBoxFrame.cpp  line 1403] 
         nsBoxFrame::PaintChildren      
[d:\builds\6.01\mozilla\layout\xul\base\src\nsBoxFrame.cpp  line 1539] 
         nsBoxFrame::Paint      
[d:\builds\6.01\mozilla\layout\xul\base\src\nsBoxFrame.cpp  line 1357] 
         nsBoxFrame::PaintChild 
[d:\builds\6.01\mozilla\layout\xul\base\src\nsBoxFrame.cpp  line 1403] 
         nsBoxFrame::PaintChildren      
[d:\builds\6.01\mozilla\layout\xul\base\src\nsBoxFrame.cpp  line 1539] 
         nsBoxFrame::Paint      
[d:\builds\6.01\mozilla\layout\xul\base\src\nsBoxFrame.cpp  line 1357] 
         nsBoxFrame::PaintChild 
[d:\builds\6.01\mozilla\layout\xul\base\src\nsBoxFrame.cpp  line 1403] 
         nsBoxFrame::PaintChildren      
[d:\builds\6.01\mozilla\layout\xul\base\src\nsBoxFrame.cpp  line 1539] 
         nsBoxFrame::Paint      
[d:\builds\6.01\mozilla\layout\xul\base\src\nsBoxFrame.cpp  line 1357] 
         nsBoxFrame::PaintChild 
[d:\builds\6.01\mozilla\layout\xul\base\src\nsBoxFrame.cpp  line 1403] 
         nsBoxFrame::PaintChildren      
[d:\builds\6.01\mozilla\layout\xul\base\src\nsBoxFrame.cpp  line 1539] 
         nsBoxFrame::Paint      
[d:\builds\6.01\mozilla\layout\xul\base\src\nsBoxFrame.cpp  line 1357] 
         nsBoxFrame::PaintChild 
[d:\builds\6.01\mozilla\layout\xul\base\src\nsBoxFrame.cpp  line 1403] 
         nsBoxFrame::PaintChildren      
[d:\builds\6.01\mozilla\layout\xul\base\src\nsBoxFrame.cpp  line 1539] 
         nsBoxFrame::Paint      
[d:\builds\6.01\mozilla\layout\xul\base\src\nsBoxFrame.cpp  line 1357] 
         nsBoxFrame::PaintChild 
[d:\builds\6.01\mozilla\layout\xul\base\src\nsBoxFrame.cpp  line 1403] 
         nsBoxFrame::PaintChildren      
[d:\builds\6.01\mozilla\layout\xul\base\src\nsBoxFrame.cpp  line 1539] 
         nsBoxFrame::Paint      
[d:\builds\6.01\mozilla\layout\xul\base\src\nsBoxFrame.cpp  line 1357] 
         nsBoxFrame::PaintChild 
[d:\builds\6.01\mozilla\layout\xul\base\src\nsBoxFrame.cpp  line 1403] 
         nsBoxFrame::PaintChildren      
[d:\builds\6.01\mozilla\layout\xul\base\src\nsBoxFrame.cpp  line 1539] 
         nsBoxFrame::Paint      
[d:\builds\6.01\mozilla\layout\xul\base\src\nsBoxFrame.cpp  line 1357] 
         nsBoxFrame::PaintChild 
[d:\builds\6.01\mozilla\layout\xul\base\src\nsBoxFrame.cpp  line 1403] 
         nsBoxFrame::PaintChildren      
[d:\builds\6.01\mozilla\layout\xul\base\src\nsBoxFrame.cpp  line 1539] 
         nsBoxFrame::Paint      
[d:\builds\6.01\mozilla\layout\xul\base\src\nsBoxFrame.cpp  line 1357] 
         nsBoxFrame::PaintChild 
[d:\builds\6.01\mozilla\layout\xul\base\src\nsBoxFrame.cpp  line 1403] 
         nsBoxFrame::PaintChildren      
[d:\builds\6.01\mozilla\layout\xul\base\src\nsBoxFrame.cpp  line 1539] 
         nsBoxFrame::Paint      
[d:\builds\6.01\mozilla\layout\xul\base\src\nsBoxFrame.cpp  line 1357] 
         nsContainerFrame::PaintChild   
[d:\builds\6.01\mozilla\layout\html\base\src\nsContainerFrame.cpp  line 211] 
         nsContainerFrame::PaintChildren        
[d:\builds\6.01\mozilla\layout\html\base\src\nsContainerFrame.cpp  line 155] 
         nsContainerFrame::Paint        
[d:\builds\6.01\mozilla\layout\html\base\src\nsContainerFrame.cpp  line 134] 
         PresShell::Paint       
[d:\builds\6.01\mozilla\layout\html\base\src\nsPresShell.cpp  line 4664] 
         nsView::Paint  [d:\builds\6.01\mozilla\view\src\nsView.cpp  line 284] 
         nsViewManager2::RenderDisplayListElement       
[d:\builds\6.01\mozilla\view\src\nsViewManager2.cpp  line 859] 
         nsViewManager2::RenderViews    
[d:\builds\6.01\mozilla\view\src\nsViewManager2.cpp  line 806] 
         nsViewManager2::Refresh        
[d:\builds\6.01\mozilla\view\src\nsViewManager2.cpp  line 686] 
         nsViewManager2::DispatchEvent  
[d:\builds\6.01\mozilla\view\src\nsViewManager2.cpp  line 1352] 
         HandleEvent    [d:\builds\6.01\mozilla\view\src\nsView.cpp  line 68] 
         nsWindow::DispatchEvent        
[d:\builds\6.01\mozilla\widget\src\windows\nsWindow.cpp  line 686] 
         nsWindow::DispatchWindowEvent  
[d:\builds\6.01\mozilla\widget\src\windows\nsWindow.cpp  line 708] 
         nsWindow::OnPaint      
[d:\builds\6.01\mozilla\widget\src\windows\nsWindow.cpp  line 3721] 
         nsWindow::ProcessMessage       
[d:\builds\6.01\mozilla\widget\src\windows\nsWindow.cpp  line 2815] 
         nsWindow::WindowProc   
[d:\builds\6.01\mozilla\widget\src\windows\nsWindow.cpp  line 959] 
         USER32.DLL + 0x48dc (0x77e148dc)  
         USER32.DLL + 0x63fb (0x77e163fb)  
         USER32.DLL + 0x643d (0x77e1643d)  
         ntdll.dll + 0x1f04b (0x77f9f04b)  
         USER32.DLL + 0x166fd (0x77e266fd)  
         nsAppShellService::Run 
[d:\builds\6.01\mozilla\xpfe\appshell\src\nsAppShellService.cpp  line 408] 
         netscp6.exe + 0x167f (0x0040167f)  
         netscp6.exe + 0x11b8 (0x004011b8)  
    nsTextFrame::PaintAsciiText a4e6015e
        d:/builds/6.01/mozilla/layout/html/base/src/nsTextFrame.cpp line 2542
        Build: 2001013114 CrashDate: 2001-02-26 UptimeMinutes: 5  Total: 162 
        OS: Windows 95  4.0 build 67306684
        URL: 
        Comment: trying to "import" exisitng local address books
         Detailed : http://cyclone/reports/incidenttemplate.cfm?bbid=26970623
         StackTrace: 
http://cyclone/reports/stackcommentemail.cfm?dynamicBBID=26970623
     (26970623) Comments: trying to "import" exisitng local address books

    nsTextFrame::PaintAsciiText dfa9941e
        d:/builds/6.01/mozilla/layout/html/base/src/nsTextFrame.cpp line 2542
        Build: 2001013114 CrashDate: 2001-02-26 UptimeMinutes: 23  Total: 551 
        OS: Windows 98  4.90 build 73010104
     (26971992) Comments: Trying to import address bokk. clicked back ffom the 
page asking for type of book to import

    nsTextFrame::PaintAsciiText 69102fdf
        d:/builds/6.01/mozilla/layout/html/base/src/nsTextFrame.cpp line 2542
        Build: 2001013114 CrashDate: 2001-02-26 UptimeMinutes: 906  Total: 906 
        OS: Windows NT  5.0 build 2195
     (26980362) URL: http://antivirus.cai.com/

    nsTextFrame::PaintAsciiText 69102fdf
        d:/builds/6.01/mozilla/layout/html/base/src/nsTextFrame.cpp line 2542
        Build: 2001013114 CrashDate: 2001-02-26 UptimeMinutes: 9777  Total: 
17841 
        OS: Windows NT  5.0 build 2195

    nsTextFrame::PaintAsciiText 29c24281
        d:/builds/6.01/mozilla/layout/html/base/src/nsTextFrame.cpp line 2542
        Build: 2001013114 CrashDate: 2001-02-27 UptimeMinutes: 923  Total: 3624 
        OS: Windows 98  4.90 build 73010104

    nsTextFrame::PaintAsciiText 1a0c8ab6
        d:/builds/6.01/mozilla/layout/html/base/src/nsTextFrame.cpp line 2542
        Build: 2001013114 CrashDate: 2001-02-27 UptimeMinutes: 1489  Total: 
10232 
        OS: Windows 98  4.10 build 67766446
        URL: 
     (26992560) Comments: typing text into a field. text fields in geko are 
flakey at best

    nsTextFrame::PaintAsciiText f8f9df08
        d:/builds/6.01/mozilla/layout/html/base/src/nsTextFrame.cpp line 2542
        Build: 2001013114 CrashDate: 2001-02-27 UptimeMinutes: 211  Total: 4572 
        OS: Windows NT  5.0 build 2195
     (26999642) URL: www.webaid.nu

    nsTextFrame::PaintAsciiText 69102fdf
        d:/builds/6.01/mozilla/layout/html/base/src/nsTextFrame.cpp line 2542
        Build: 2001013114 CrashDate: 2001-02-27 UptimeMinutes: 699  Total: 2975 
        OS: Windows NT  5.0 build 2195
     (27014959) Comments: Reading Current Messages???? 

    nsTextFrame::PaintAsciiText dfa9941e
        d:/builds/6.01/mozilla/layout/html/base/src/nsTextFrame.cpp line 2542
        Build: 2001013114 CrashDate: 2001-02-27 UptimeMinutes: 9  Total: 9 
        OS: Windows 98  4.90 build 73010104
     (27015492) Comments: opened tools

    nsTextFrame::PaintAsciiText 04f3d63c
        d:/builds/6.01/mozilla/layout/html/base/src/nsTextFrame.cpp line 2542
        Build: 2001013114 CrashDate: 2001-02-27 UptimeMinutes: 231  Total: 231 
        OS: Windows 98  4.10 build 67766222
     (27024493) Comments: Importing Address Book from Outlook Express.

    nsTextFrame::PaintAsciiText 69102fdf
        d:/builds/6.01/mozilla/layout/html/base/src/nsTextFrame.cpp line 2542
        Build: 2001013114 CrashDate: 2001-02-28 UptimeMinutes: 345  Total: 886 
        OS: Windows NT  5.0 build 2195
     (27049107) Comments: Moving mails from sent to another folder

    nsTextFrame::PaintAsciiText 9c1f53fe
        d:/builds/6.01/mozilla/layout/html/base/src/nsTextFrame.cpp line 2542
        Build: 2001013114 CrashDate: 2001-02-28 UptimeMinutes: 960  Total: 1061 
        OS: Windows NT  5.0 build 2195
     (27095261) Comments: Copying e-mail from inbox to a folder
Keywords: topcrash
Reassigning to erik.
Assignee: karnaze → erik
Keywords: mozilla0.9
Frank, since I'm working on bidi right now, perhaps Shanjian, our super-hero,
could work on this top-crasher?
Assignee: erik → ftang
shanjian- can you also take a look at this one?
Assignee: ftang → shanjian
The testcase provided in this bug report is no longer reproducible. I update
my local tree today and still could not reproduce it. It might be fixed by 
some other fixes. I will close this bug as worksforme. Please verify and 
reopen the bug if you see a different behavior.
Status: NEW → RESOLVED
Closed: 23 years ago
Resolution: --- → WORKSFORME
*** Bug 66856 has been marked as a duplicate of this bug. ***
I forgot to mention. I tried several of the testcases provided by talkback, and none of 
them could crash my browser. 
It should be easy to check talkback and see if it's still there. In that case 
this bug should be opened. Otherwise, it really is gone.
Most of the crashes mentioned in this bug were happening a lot with the N601 
release, but there haven't been too many crashes of this kind in recent builds.  

I took a look at Talkback data and found out that a similar crash (the stack 
trace looks almost identical, except for line number differences due to changes 
in the code) has been logged in bug 75305 and is about to get fixed.  I don't 
know if it's the same issue or a completely different problem, but if someone 
can take a look to see if it's a dup, that would be great.
It is really hard to tell. In bug 75305, kin mentioned the problem is caused
by a race condition reflow and paint event process. That is very reasonable. 
When I was lokking into bug 66856, which I marked as duplicate of this one, 
I could not spot anything suspecious just within paintAscii function and 
its near context. If the problem is caused by a race condition, any irrelavant 
change could make the problem go away or reappear. Let's see what's happenning 
after kin check in his fix. 
Even though I check in my fix (which is for the editor) this race condition will 
still be present ... and can probably be reproduced by shortening a textnode 
with a DOM call via JS.

This bug should really be reopened ... if you want a reproduceable test case, 
use the steps in bug 75305.
I will reopen this bug.
Status: RESOLVED → REOPENED
Resolution: WORKSFORME → ---
Please refer to bug 75305. The problem seems caused by a race condition of 
processing reflow and paint event. This is really not an i18n issue. I could  
not fix this bug promptly. Reassign to layout group.
Assignee: shanjian → waterson
Status: REOPENED → NEW
I just attatched an HTML file that mimics what the editor was doing. This test 
case proves that the race condition happens outside the editor context.
Moving to m1.0.1.
Target Milestone: --- → mozilla1.0.1
If we're not going to look into fixing this before mozilla1.0 shouldn't we at 
least put an assertion in the nsTextFrame paint code that checks to make sure 
that mContentLength is <= to the length the of the text fragment? And if not, 
bail early with an error instead of crashing?
karnaze, why are you abusing a post-1.0 milestone?  That means Future right now,
and Future communicates better what your setting can only mean.

What about putting in some defensive code sooner, as kin asked.  How about
finding another owner who might fix this sooner?  Normally, we don't punt
topcrash bugs off to Future/helpwanted.  Are you trying to say that this is not
a topcrash?  Oh, I just noticed this is assigned to waterson.

waterson: what's the right answer here?

/be
Prior to kin attaching the test case at 2pm today, there wasn't an easy way to 
reproduce this. Sure, I'd be happy to try to fix this sooner. My bug list is 
slowly approaching unreality, though.
Status: NEW → ASSIGNED
Target Milestone: mozilla1.0.1 → mozilla0.9.1
I just wanted to again mention that although this crash was indeed a 
"topcrasher" for the Netscape 6.01 release...according to Talkback data for the 
most recent milestones and daily builds, this has only occurred a few times 
(actually only 3 times) since build 2001013114.  I don't think this really 
qualifies as a topcrasher right now...unless someone can easily reproduce this 
and thinks that N6 users might run into this problem again after another major 
release like Netscape 6.5.  Just my 2 cents.
Ok, removing topcrash.

/be
Keywords: mozilla0.9, topcrash → mozilla0.9.1
PDT would like to get Kin's suggestion from 4/19 17:05 implemented for m.9.1 and
defer the rest of this.
Keywords: patch
r=karnaze

sr=attinasi for patch 35931
fix checked in.
Status: ASSIGNED → RESOLVED
Closed: 23 years ago → 23 years ago
Resolution: --- → FIXED
Marking verified in the May 30th build (200153009).
Status: RESOLVED → VERIFIED
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: