Closed Bug 73291 Opened 24 years ago Closed 23 years ago

invalid memory reference shortening text element in onload handler

Categories

(Core :: Layout, defect)

x86
Windows 2000
defect
Not set
major

Tracking

()

VERIFIED FIXED
mozilla0.9.1

People

(Reporter: danm.moz, Assigned: waterson)

References

Details

(Keywords: crash)

Attachments

(2 files)

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: 24 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
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: 24 years ago23 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: