Closed
Bug 110898
Opened 23 years ago
Closed 23 years ago
M098 Trunk crash rendering text [@ nsRenderingContextWin::GetTextDimensions]
Categories
(Core :: Layout, defect)
Tracking
()
VERIFIED
FIXED
mozilla1.0
People
(Reporter: greer, Assigned: shanjian)
References
Details
(Keywords: crash, topcrash, Whiteboard: [adt1][need teruko to verify fix])
Crash Data
Attachments
(2 files, 5 obsolete files)
14.21 KB,
text/plain
|
Details | |
7.51 KB,
patch
|
shanjian
:
review+
attinasi
:
superreview+
asa
:
approval+
|
Details | Diff | Splinter Review |
This one is showing up in the early M096 branch talkback crash reports as well as in the Trunk. I have tried to reproduce it (with build 2001111817) but all of the M096 crashes are on a Win95 machine. Here is the stack with user given URLs below: Stack Trace: nsRenderingContextWin::GetTextDimensions [d:\builds\seamonkey\mozilla\gfx\src\windows\nsRenderingContextWin.cpp line 2074] nsTextFrame::MeasureText [d:\builds\seamonkey\mozilla\layout\html\base\src\nsTextFrame.cpp line 4658] nsTextFrame::Reflow [d:\builds\seamonkey\mozilla\layout\html\base\src\nsTextFrame.cpp line 5114] nsLineLayout::ReflowFrame [d:\builds\seamonkey\mozilla\layout\html\base\src\nsLineLayout.cpp line 1038] nsBlockFrame::ReflowInlineFrame [d:\builds\seamonkey\mozilla\layout\html\base\src\nsBlockFrame.cpp line 3675] nsBlockFrame::DoReflowInlineFrames [d:\builds\seamonkey\mozilla\layout\html\base\src\nsBlockFrame.cpp line 3556] nsBlockFrame::DoReflowInlineFramesAuto [d:\builds\seamonkey\mozilla\layout\html\base\src\nsBlockFrame.cpp line 3481] nsBlockFrame::ReflowInlineFrames [d:\builds\seamonkey\mozilla\layout\html\base\src\nsBlockFrame.cpp line 3426] nsBlockFrame::ReflowLine [d:\builds\seamonkey\mozilla\layout\html\base\src\nsBlockFrame.cpp line 2493] nsBlockFrame::ReflowDirtyLines [d:\builds\seamonkey\mozilla\layout\html\base\src\nsBlockFrame.cpp line 2150] nsBlockFrame::Reflow [d:\builds\seamonkey\mozilla\layout\html\base\src\nsBlockFrame.cpp line 826] nsBlockReflowContext::DoReflowBlock [d:\builds\seamonkey\mozilla\layout\html\base\src\nsBlockReflowContext.cpp line 581] nsBlockReflowContext::ReflowBlock [d:\builds\seamonkey\mozilla\layout\html\base\src\nsBlockReflowContext.cpp line 359] nsBlockFrame::ReflowBlockFrame [d:\builds\seamonkey\mozilla\layout\html\base\src\nsBlockFrame.cpp line 3169] nsBlockFrame::ReflowLine [d:\builds\seamonkey\mozilla\layout\html\base\src\nsBlockFrame.cpp line 2372] nsBlockFrame::ReflowDirtyLines [d:\builds\seamonkey\mozilla\layout\html\base\src\nsBlockFrame.cpp line 2150] nsBlockFrame::Reflow [d:\builds\seamonkey\mozilla\layout\html\base\src\nsBlockFrame.cpp line 826] nsContainerFrame::ReflowChild [d:\builds\seamonkey\mozilla\layout\html\base\src\nsContainerFrame.cpp line 737] CanvasFrame::Reflow [d:\builds\seamonkey\mozilla\layout\html\base\src\nsHTMLFrame.cpp line 570] nsBoxToBlockAdaptor::Reflow [d:\builds\seamonkey\mozilla\layout\xul\base\src\nsBoxToBlockAdaptor.cpp line 891] nsBoxToBlockAdaptor::DoLayout [d:\builds\seamonkey\mozilla\layout\xul\base\src\nsBoxToBlockAdaptor.cpp line 540] nsBox::Layout [d:\builds\seamonkey\mozilla\layout\xul\base\src\nsBox.cpp line 1002] nsScrollBoxFrame::DoLayout [d:\builds\seamonkey\mozilla\layout\xul\base\src\nsScrollBoxFrame.cpp line 392] nsBox::Layout [d:\builds\seamonkey\mozilla\layout\xul\base\src\nsBox.cpp line 1002] nsContainerBox::LayoutChildAt [d:\builds\seamonkey\mozilla\layout\xul\base\src\nsContainerBox.cpp line 653] nsGfxScrollFrameInner::LayoutBox [d:\builds\seamonkey\mozilla\layout\html\base\src\nsGfxScrollFrame.cpp line 1027] nsGfxScrollFrameInner::Layout [d:\builds\seamonkey\mozilla\layout\html\base\src\nsGfxScrollFrame.cpp line 1138] nsGfxScrollFrame::DoLayout [d:\builds\seamonkey\mozilla\layout\html\base\src\nsGfxScrollFrame.cpp line 1035] nsBox::Layout [d:\builds\seamonkey\mozilla\layout\xul\base\src\nsBox.cpp line 1002] nsBoxFrame::Reflow [d:\builds\seamonkey\mozilla\layout\xul\base\src\nsBoxFrame.cpp line 928] nsGfxScrollFrame::Reflow [d:\builds\seamonkey\mozilla\layout\html\base\src\nsGfxScrollFrame.cpp line 753] nsContainerFrame::ReflowChild [d:\builds\seamonkey\mozilla\layout\html\base\src\nsContainerFrame.cpp line 737] ViewportFrame::Reflow [d:\builds\seamonkey\mozilla\layout\html\base\src\nsViewportFrame.cpp line 576] nsHTMLReflowCommand::Dispatch [d:\builds\seamonkey\mozilla\layout\html\base\src\nsHTMLReflowCommand.cpp line 217] PresShell::ProcessReflowCommand [d:\builds\seamonkey\mozilla\layout\html\base\src\nsPresShell.cpp line 6017] PresShell::ProcessReflowCommands [d:\builds\seamonkey\mozilla\layout\html\base\src\nsPresShell.cpp line 6072] ReflowEvent::HandleEvent [d:\builds\seamonkey\mozilla\layout\html\base\src\nsPresShell.cpp line 5928] PL_HandleEvent [d:\builds\seamonkey\mozilla\xpcom\threads\plevent.c line 591] PL_ProcessPendingEvents [d:\builds\seamonkey\mozilla\xpcom\threads\plevent.c line 524] _md_EventReceiverProc [d:\builds\seamonkey\mozilla\xpcom\threads\plevent.c line 1072] KERNEL32.DLL + 0x2239f (0xbff9239f) 0x00688c00 Source File : http://bonsai.mozilla.org/cvsblame.cgi?file=mozilla/gfx/src/windows/nsRenderingContextWin.cpp line : 2074 (38172423) URL: http://kbic.ardour.co.jp/~newgenji/oldbook/sgenji.html (38167970) URL: http://prom.alphaloop.com/i/ (38146123) URL: http://prom.alphaloop.com/i/ (38090557) URL: http://www.megabbs.com/cgi-bin/readres.cgi?bo=sisou&vi=1000801879 (38031982) URL: http://www.megabbs.com/cgi-bin/readres.cgi?bo=lobby&vi=993360966
I suspect this may have now been fixed by my recent checkin in bug 110174.
Marking FIXED per my above comment. The stack trace here is the same as that in bug 110174 comment #2. And looking at the crash data, http://ftp.mozilla.org/pub/data/crash-data/ the crash has stopped since the day I landed the fix for that bug. For future reference: all the loose ends that I can think of in the font sub-system have now been fixed since my revamps. So if this bug re-appears, meaning the font sub-system is genuinely unable to find a font (e.g., in low memory situations), it would be alright to add a null check as indicated below (i.e., without the guilt of feeling that an underlying bug is being masked without proper investigation): 1991 NS_IMETHODIMP 1992 nsRenderingContextWin::GetTextDimensions(... with break indices ...) [...] 2064 nsFontWin* fontWin = (nsFontWin*)fonts[0]; 2065 aDimensions.ascent = fontWin->mMaxAscent; 2066 aDimensions.descent = fontWin->mMaxDescent; 2067 2068 // fast path - normal case, quick return if there is only one font 2069 if (fonts.Count() == 1) 2070 return NS_OK; with: + count = fonts.Count(); + if (!count) + return NS_OK; 2064 nsFontWin* fontWin = (nsFontWin*)fonts[0]; 2065 aDimensions.ascent = fontWin->mMaxAscent; 2066 aDimensions.descent = fontWin->mMaxDescent; 2067 2068 // fast path - normal case, quick return if there is only one font -2069 if (fonts.Count() == 1) +2069 if (count == 1) 2070 return NS_OK;
Status: NEW → RESOLVED
Closed: 23 years ago
Resolution: --- → FIXED
Comment 6•23 years ago
|
||
verified fixed. i haven't seen this crash in recent MozillaTrunk Talkback data.
Status: RESOLVED → VERIFIED
Summary: M096 (branch) Trunk crash rendering text [@ nsRenderingContextWin::GetTextDimensions] → M096 Trunk crash rendering text [@ nsRenderingContextWin::GetTextDimensions]
Reopening. Seeing this bug on the Trunk in builds 2002-01-16 to present.
Status: VERIFIED → REOPENED
Resolution: FIXED → ---
Summary: M096 Trunk crash rendering text [@ nsRenderingContextWin::GetTextDimensions] → M096 Trunk crash rendering text [@ nsRenderingContextWin::GetTextDimensions][@ nsTextFrame::MeasureText]
Same stack as bug 117736, with the stack ending one frame earlier in that bug. Probably a dupe. The latest incidents for this one began 2002-01-16.
Comment 11•23 years ago
|
||
Taking the bug since I have a fix. Requesting r=shanjian, sr=waterson http://bugzilla.mozilla.org/attachment.cgi?id=66005&action=view The null pointer is happening because no font was found/created during glyph resolution (not even the fallback substitute font). This usually suggests a bigger fish, e.g., bug 117736 mentioned above (which is about the problem that layout is kicked off when the world is being torn down), but a null font may possibly happen when memory and other resources are low.
Assignee: attinasi → rbs
Status: REOPENED → NEW
Assignee | ||
Comment 12•23 years ago
|
||
Comment on attachment 66005 [details] [diff] [review] null check before deferencing the pointer r=shanjian I am OK with patch, but how about the big fish? Are you able to reproduce it?
Attachment #66005 -
Flags: review+
Comment 13•23 years ago
|
||
Yep, see bug 117736 comment #9.
Comment 14•23 years ago
|
||
So is Bug 117736 a dup of this one?
Any chance of getting this patch in soon? waterson is on sabbatical, so you might want to ask attinasi to sr.
Comment 17•23 years ago
|
||
Comment on attachment 70156 [details] [diff] [review] same safeguard -- the syntax here is based on what I said in comment #5 carrying r=shanjian forward
Attachment #70156 -
Flags: review+
Status: NEW → ASSIGNED
Summary: M096 Trunk crash rendering text [@ nsRenderingContextWin::GetTextDimensions][@ nsTextFrame::MeasureText] → [fix, awaiting sr= & a=] M096 Trunk crash rendering text [@ nsRenderingContextWin::GetTextDimensions][@ nsTextFrame::MeasureText]
Whiteboard: have: r=shanjian; awaiting: sr=attinasi & a=
Keywords: mozilla0.9.9
Comment 19•23 years ago
|
||
Comment on attachment 70156 [details] [diff] [review] same safeguard -- the syntax here is based on what I said in comment #5 sr=attinasi, but I would like to see an ASSERTION that fontWin is not null before the deref, assuming that a non-zero count means that fonts[0] MUST return a valid font.
Attachment #70156 -
Flags: superreview+
Comment 20•23 years ago
|
||
Attachment #70156 -
Attachment is obsolete: true
Comment 21•23 years ago
|
||
Comment on attachment 71513 [details] [diff] [review] updated patch - includes requested assertion carrying r/sr forward
Attachment #71513 -
Flags: superreview+
Attachment #71513 -
Flags: review+
Comment 22•23 years ago
|
||
Comment on attachment 71513 [details] [diff] [review] updated patch - includes requested assertion a=shaver for 0.9.9
Attachment #71513 -
Flags: approval+
Comment 23•23 years ago
|
||
Checked in.
Status: ASSIGNED → RESOLVED
Closed: 23 years ago → 23 years ago
Resolution: --- → FIXED
Summary: [fix, awaiting sr= & a=] M096 Trunk crash rendering text [@ nsRenderingContextWin::GetTextDimensions][@ nsTextFrame::MeasureText] → M096 Trunk crash rendering text [@ nsRenderingContextWin::GetTextDimensions][@ nsTextFrame::MeasureText]
Whiteboard: have: r=shanjian; awaiting: sr=attinasi & a=
Comment 24•23 years ago
|
||
Removing [@ nsTextFrame::MeasureText] from summary, since that crash is covered by bug 117736 (which I just verified fixed). However, reopening this bug for now for more investigation. I see 3 talkback incidents reported with 2/27 builds (after the checkin on 2/26). Here is the most recent incident: Incident ID 3447792 Stack Signature nsRenderingContextWin::GetTextDimensions 9192f6d0 Trigger Time 2002-02-27 15:53:55 Email Address URL visited Build ID 2002022709 Product ID MozillaTrunk Platform Operating System Win32 Module Trigger Reason Access violation User Comments Stack Trace nsRenderingContextWin::GetTextDimensions [d:\builds\seamonkey\mozilla\gfx\src\windows\nsRenderingContextWin.cpp, line 1628] nsTextFrame::MeasureText [d:\builds\seamonkey\mozilla\layout\html\base\src\nsTextFrame.cpp, line 4826] nsTextFrame::Reflow [d:\builds\seamonkey\mozilla\layout\html\base\src\nsTextFrame.cpp, line 5292] nsLineLayout::ReflowFrame [d:\builds\seamonkey\mozilla\layout\html\base\src\nsLineLayout.cpp, line 1087] nsBlockFrame::ReflowInlineFrame [d:\builds\seamonkey\mozilla\layout\html\base\src\nsBlockFrame.cpp, line 3737] nsBlockFrame::DoReflowInlineFrames [d:\builds\seamonkey\mozilla\layout\html\base\src\nsBlockFrame.cpp, line 3618] nsBlockFrame::DoReflowInlineFramesAuto [d:\builds\seamonkey\mozilla\layout\html\base\src\nsBlockFrame.cpp, line 3543] nsBlockFrame::ReflowInlineFrames [d:\builds\seamonkey\mozilla\layout\html\base\src\nsBlockFrame.cpp, line 3488] nsBlockFrame::ReflowLine [d:\builds\seamonkey\mozilla\layout\html\base\src\nsBlockFrame.cpp, line 2642] nsBlockFrame::ReflowDirtyLines [d:\builds\seamonkey\mozilla\layout\html\base\src\nsBlockFrame.cpp, line 2281] nsBlockFrame::Reflow [d:\builds\seamonkey\mozilla\layout\html\base\src\nsBlockFrame.cpp, line 846] nsBlockReflowContext::DoReflowBlock [d:\builds\seamonkey\mozilla\layout\html\base\src\nsBlockReflowContext.cpp, line 581] nsBlockReflowContext::ReflowBlock [d:\builds\seamonkey\mozilla\layout\html\base\src\nsBlockReflowContext.cpp, line 359] nsBlockFrame::ReflowBlockFrame [d:\builds\seamonkey\mozilla\layout\html\base\src\nsBlockFrame.cpp, line 3232] nsBlockFrame::ReflowLine [d:\builds\seamonkey\mozilla\layout\html\base\src\nsBlockFrame.cpp, line 2508] nsBlockFrame::ReflowDirtyLines [d:\builds\seamonkey\mozilla\layout\html\base\src\nsBlockFrame.cpp, line 2281] nsBlockFrame::Reflow [d:\builds\seamonkey\mozilla\layout\html\base\src\nsBlockFrame.cpp, line 846] nsBlockReflowContext::DoReflowBlock [d:\builds\seamonkey\mozilla\layout\html\base\src\nsBlockReflowContext.cpp, line 581] nsBlockReflowContext::ReflowBlock [d:\builds\seamonkey\mozilla\layout\html\base\src\nsBlockReflowContext.cpp, line 359] nsBlockFrame::ReflowBlockFrame [d:\builds\seamonkey\mozilla\layout\html\base\src\nsBlockFrame.cpp, line 3232] nsBlockFrame::ReflowLine [d:\builds\seamonkey\mozilla\layout\html\base\src\nsBlockFrame.cpp, line 2508] nsBlockFrame::ReflowDirtyLines [d:\builds\seamonkey\mozilla\layout\html\base\src\nsBlockFrame.cpp, line 2281] nsBlockFrame::Reflow [d:\builds\seamonkey\mozilla\layout\html\base\src\nsBlockFrame.cpp, line 846] nsContainerFrame::ReflowChild [d:\builds\seamonkey\mozilla\layout\html\base\src\nsContainerFrame.cpp, line 803] CanvasFrame::Reflow [d:\builds\seamonkey\mozilla\layout\html\base\src\nsHTMLFrame.cpp, line 564] nsBoxToBlockAdaptor::Reflow [d:\builds\seamonkey\mozilla\layout\xul\base\src\nsBoxToBlockAdaptor.cpp, line 845] nsBoxToBlockAdaptor::DoLayout [d:\builds\seamonkey\mozilla\layout\xul\base\src\nsBoxToBlockAdaptor.cpp, line 622] nsBox::Layout [d:\builds\seamonkey\mozilla\layout\xul\base\src\nsBox.cpp, line 1052] nsScrollBoxFrame::DoLayout [d:\builds\seamonkey\mozilla\layout\xul\base\src\nsScrollBoxFrame.cpp, line 395] nsBox::Layout [d:\builds\seamonkey\mozilla\layout\xul\base\src\nsBox.cpp, line 1052] nsContainerBox::LayoutChildAt [d:\builds\seamonkey\mozilla\layout\xul\base\src\nsContainerBox.cpp, line 650] nsGfxScrollFrameInner::LayoutBox [d:\builds\seamonkey\mozilla\layout\html\base\src\nsGfxScrollFrame.cpp, line 1062] nsGfxScrollFrameInner::Layout [d:\builds\seamonkey\mozilla\layout\html\base\src\nsGfxScrollFrame.cpp, line 1221] nsGfxScrollFrame::DoLayout [d:\builds\seamonkey\mozilla\layout\html\base\src\nsGfxScrollFrame.cpp, line 1070] nsBox::Layout [d:\builds\seamonkey\mozilla\layout\xul\base\src\nsBox.cpp, line 1052] nsBoxFrame::Reflow [d:\builds\seamonkey\mozilla\layout\xul\base\src\nsBoxFrame.cpp, line 1000] nsGfxScrollFrame::Reflow [d:\builds\seamonkey\mozilla\layout\html\base\src\nsGfxScrollFrame.cpp, line 779] nsContainerFrame::ReflowChild [d:\builds\seamonkey\mozilla\layout\html\base\src\nsContainerFrame.cpp, line 803] ViewportFrame::Reflow [d:\builds\seamonkey\mozilla\layout\html\base\src\nsViewportFrame.cpp, line 574] nsHTMLReflowCommand::Dispatch [d:\builds\seamonkey\mozilla\layout\html\base\src\nsHTMLReflowCommand.cpp, line 217] PresShell::ProcessReflowCommand [d:\builds\seamonkey\mozilla\layout\html\base\src\nsPresShell.cpp, line 6205] PresShell::ProcessReflowCommands [d:\builds\seamonkey\mozilla\layout\html\base\src\nsPresShell.cpp, line 6260] ReflowEvent::HandleEvent [d:\builds\seamonkey\mozilla\layout\html\base\src\nsPresShell.cpp, line 6116] PL_HandleEvent [d:\builds\seamonkey\mozilla\xpcom\threads\plevent.c, line 591] PL_ProcessPendingEvents [d:\builds\seamonkey\mozilla\xpcom\threads\plevent.c, line 524] _md_EventReceiverProc [d:\builds\seamonkey\mozilla\xpcom\threads\plevent.c, line 1072] KERNEL32.DLL + 0x2239f (0xbff9239f) 0x00648c18 From the stack, it looks like this crash is still happening.
Status: RESOLVED → REOPENED
Resolution: FIXED → ---
Summary: M096 Trunk crash rendering text [@ nsRenderingContextWin::GetTextDimensions][@ nsTextFrame::MeasureText] → M096 Trunk crash rendering text [@ nsRenderingContextWin::GetTextDimensions]
Reporter | ||
Comment 25•23 years ago
|
||
Updating the summary with M098. Todays's data for the last ten days contains: M098 (nsRenderingContextWin::GetTextDimensions): 48 crashes Trunk (nsRenderingContextWin::GetTextDimensions): 22 crashes
Summary: M096 Trunk crash rendering text [@ nsRenderingContextWin::GetTextDimensions] → M098 Trunk crash rendering text [@ nsRenderingContextWin::GetTextDimensions]
This is the #3 unfixed topcrash in builds for the past few days? Any idsea what's going on here?
Comment 27•23 years ago
|
||
Line numbers look different. The current crashes seem to be happening in the ASCII path, GetTextDimensions(char *...), whereas the previous crashes where on the Unicode path, GetTextDimensions(PRUnichar *...) and the patch only covered there.
Status: REOPENED → ASSIGNED
Reporter | ||
Comment 28•23 years ago
|
||
*** Bug 128643 has been marked as a duplicate of this bug. ***
Reporter | ||
Comment 29•23 years ago
|
||
rbs: attached is a file with a sample of typical crashes from M099 and the Trunk at this signature. Regarding your comment #27, if this is a different problem requiring a different patch, can we mark this one fixed and open another bug for the crash in the ASCII path? There are currently 36 incidents (from 16 users) in M099 and 31 incidents (from 7 users, testing builds 3-05 to 3-13) on the Trunk.
Comment 30•23 years ago
|
||
It just needs the same kind of null checks in the other flavors of that function. (but doing this in the dark since the crashes are no reproducable by developpers or QAs)
Comment 31•23 years ago
|
||
I made a null-check patch and was testing for code coverage. To this end, I set |useAfunctions = 1| to test that all remained fine with the 'A' versions (i.e., this is the code that get used on Win95-Japanese -- which seems to be the platform where these crashes are reported). But to my surprise, I am hitting the assertion: NS_ERROR("must call nsFontSubset's GetWidth"); Stack trace: nsFontWinA::GetWidth(HDC__ * 0x330103d9, const unsigned short * 0x00126dcc, unsigned int 1) line 4472 + 21 bytes do_GetTextDimensions(const nsFontSwitch * 0x001268a0, const unsigned short * 0x00126dcc, unsigned int 1, void * 0x001268e0) line 2186 + 25 bytes nsFontMetricsWinA::ResolveForwards(HDC__ * 0x330103d9, const unsigned short * 0x00126dcc, unsigned int 1, int (const nsFontSwitch *, const unsigned short *, unsigned int, void *)* 0x012dc7f0 do_GetTextDimensions(const nsFontSwitch *, const unsigned short *, unsigned int, void *), void * 0x001268e0) line 4974 + 24 bytes nsRenderingContextWin::GetTextDimensions(nsRenderingContextWin * const 0x03e5fe48, const unsigned short * 0x00126dcc, unsigned int 1, nsTextDimensions & {...}, int * 0x00000000) line 2212 nsTextFrame::MeasureText(nsIPresContext * 0x03db9b80, const nsHTMLReflowState & {...}, nsTextTransformer & {...}, nsILineBreaker * 0x03e21598, nsTextFrame::TextStyle & {...}, nsTextFrame::TextReflowData & {...}) line 4767 nsTextFrame::Reflow(nsTextFrame * const 0x03e6f930, nsIPresContext * 0x03db9b80, nsHTMLReflowMetrics & {...}, const nsHTMLReflowState & {...}, unsigned int & 0) line 5294 + 43 bytes ============== shanjian, care to try useAfunctions = 1 in your tree and visit: http://asahi.jp/ I would like to first confirm that nsFontMetricsWinA::ResolveForwards() that you added is still up-to-date and that I am not seeing things.
Comment 32•23 years ago
|
||
shanjian, did you try useAfunctions. I left it in my tree and am seeing crashes in my browsing (MathML pages with those code points). Pretty weird.
Comment 33•23 years ago
|
||
re-assigning to shanjian. I already have the null checks in my tree since comment #31 on 2002-03-15. Please re-assign to me if you have a pointer as to what is happening re: my query above. I would like to commit the null checks in m1.0.
Assignee: rbs → shanjian
Status: ASSIGNED → NEW
Keywords: mozilla0.9.9 → mozilla1.0
Target Milestone: mozilla0.9.9 → mozilla1.0
Comment 34•23 years ago
|
||
Is the approved patch from 02/26/02 still valid? If not can you please obsolete the patch? Thanks.
Comment 35•23 years ago
|
||
Comment on attachment 71513 [details] [diff] [review] updated patch - includes requested assertion obsoleting the patch which was already checked in.
Attachment #71513 -
Attachment is obsolete: true
Assignee | ||
Comment 38•23 years ago
|
||
The direct cause of the problem is that nsFontWin is returned directly. While most of the A-Version is expecting the pointer of nsFontSubset. This confused the system in some situation, while in others it works OK. I traced the problem back to the changes for surrogate support. The prototype for nsFontMetricsWin is changed to cope with UCS4, but prototype of correspondent nsFontMetricsWinA methods are not changed. That breaks the semantic of those virtual functions. In other word, methods in nsFontMetricsWin are called in place of nsFontMetricsWinA methods.
Assignee | ||
Comment 39•23 years ago
|
||
Assignee | ||
Comment 40•23 years ago
|
||
rbs/attinasi, could you r/sr?
Comment 41•23 years ago
|
||
Comment on attachment 77164 [details] [diff] [review] patch r=rbs
Attachment #77164 -
Flags: review+
Comment 42•23 years ago
|
||
What I had done earlier was to stick to pointers that have arealdy been null checked to get the equivalent functionality, and add a couple of null checks. Feel free to integrate my patch in yours. I applied your patch and I could get MathML pages to display --albeit with lot of questions marks as usual-- when setting the useA flag. (MathML pages exercise the font subsystem a lot because they trigger the hunt for glyphs that are no where to be found.)
Assignee | ||
Comment 43•23 years ago
|
||
Attachment #77164 -
Attachment is obsolete: true
Attachment #77202 -
Attachment is obsolete: true
Assignee | ||
Comment 44•23 years ago
|
||
I tried the patch with top 100 websites and top 100 international sites, it worked fine.
Assignee | ||
Comment 45•23 years ago
|
||
Comment on attachment 77254 [details] [diff] [review] complete patch (include rbs's nice-to-have one) carry over rbs review
Attachment #77254 -
Flags: review+
Comment 46•23 years ago
|
||
Comment on attachment 77254 [details] [diff] [review] complete patch (include rbs's nice-to-have one) sr=attinasi
Attachment #77254 -
Flags: superreview+
Comment 47•23 years ago
|
||
Comment on attachment 77254 [details] [diff] [review] complete patch (include rbs's nice-to-have one) a=asa (on behalf of drivers) for checkin to the 1.0 trunk
Attachment #77254 -
Flags: approval+
Comment 48•23 years ago
|
||
adt1.0.0 1. it is one of the top crasher 2. the bug only happen on japanese win 95, won't happen on US 95 or other windows 3. the fix is local to Japanese win95 code only. the risk is very local
Keywords: adt1.0.0
Comment 49•23 years ago
|
||
adt1.0.0+ (on ADT's behalf) for checkin into 1.0. Pls verify this in Win 95 JA, and text display on other Windows platforms.
Comment 50•23 years ago
|
||
teruko can verify the patch fix J win 95 crash or not after check in.
Assignee | ||
Comment 51•23 years ago
|
||
fix checked in.
Status: ASSIGNED → RESOLVED
Closed: 23 years ago → 23 years ago
Resolution: --- → FIXED
Comment 52•23 years ago
|
||
Since I don't have a Japanese Win 95 to verify with, could someone who has access to this system please check it ?
Updated•23 years ago
|
Whiteboard: [adt1] → [adt1][need teruko to verify fix]
Comment 53•23 years ago
|
||
I have Windows 95J system. However, when I tied to verify this on Win95 J machine, the installer failed and displayed the error message "1114: Could not load. C:\Win95J\TEMP\ns_temp\xpcom.ns\bin\xpistub.dll". I tried the different builds, 4-15-1.00, 4-16-1.00, and 4-3-trunk. I have not succeeded installing Netscape. I am investigating the problem.
Comment 54•23 years ago
|
||
Rui and I tried to install the Netscape on Win95 US machine. We got the same problem on the 4-15-1.00 and 4-04 trunk build. Any installers did not work on Win95. I logged the Win95 installer problem in bug 137879. Shanjian, do you have any suggestions to verify this bug?
Comment 55•22 years ago
|
||
have not seen any comments on this bug for almost a year now. marking it verified based on comments
Status: RESOLVED → VERIFIED
Updated•13 years ago
|
Crash Signature: [@ nsRenderingContextWin::GetTextDimensions]
You need to log in
before you can comment on or make changes to this bug.
Description
•