Closed Bug 90758 Opened 24 years ago Closed 24 years ago

Browser crash when going to any Chinese web page

Categories

(SeaMonkey :: General, defect)

Product:
SeaMonkey
Component:
General
Platform:
HP
HP-UX
Type:
defect
Priority:
Not set
Severity:
critical

Tracking

(Not tracked)

Status:
RESOLVED FIXED

People

(Reporter: jimmyu, Assigned: bstell)

References

(
URL
)

Details

Attachments

(5 files)

console output before crash
(deleted), text/plain
Details
stack trace
(deleted), text/plain
Details
mozconfig options used to build
(deleted), text/plain
Details
patch that fixes this
(deleted), patch
Details | Diff | Splinter Review
smaller patch to fix this
(deleted), patch
Details | Diff | Splinter Review
HPUX branch build 20010713 Steps to reproduce: 1) launch browser 2) URL: http://home.netscape.com/zh/tw/index.html This works fine on the Linux branch build. Also no problems with Korean,and Japanese page.
update qa and add blocker
Blocks: 18687
QA Contact: doronr → jimmyu
This works fine for me using build #2001071309 on Hpux 11i.
Looks like this is only a problem on the branch. Trunk works fine.
using the branch build i was able to see this problem on: 11.00 machines : bologna, brindisi 11i machines : napoli, esopus
Summary: Browser crash when going to a any Chinese web page → Browser crash when going to any Chinese web page
I will take a look today.
Status: NEW → ASSIGNED
I could not reproduce this with my debug build. My source code was updated yesterday. Jimmy, I would like to ask you some more info. 1, Is there any warning or other output info in text console before crash? 2, Can you reproduce this with a debug build? (Shannon might have one.) If so, please post backtrace stack here. 3, Save that page to a local file, and test it that way. Do you see a different behavior? 4, remove line "<meta HTTP-EQUIV = "Content-Type" CONTENT="text/html; charset=big5> load the page and tried to set charset through charset menu, what did you see? 5, Could you try it on venice, which has more font installed? Sorry for asking too much. It is always troublesome if a bug could not be reproduced with my debug build.
I was able to reproduce this on our 2001071709 branch build from today on sorrento and venice. I'm afraid I don't have a debug branch build right now, but as soon as I do I'll post a stack trace.
shanjian, check Talkback ID 33018423 (http://climate) for the stack trace .. there was no warning message but one output info "xmlencoding detect- big5" same thing happening when capture the page locally .. but removing that line doesn't crash the browser .. the page just display weird character .. and if i go to View|Character Coding|Chinese Traditional (big5) it will crash i tried these on both venice and bologna .. there was no debug build available that i can try ..
Thanks for prompt response. I am building a optimized build to test it now.
I just finished my optimized build, and still could not reproduce the problem. Some random guess, the problem might be related with frank's recent change in big5 conversion code. But the strange thing is, the same change is also available on trunk. Jimmy, could you do some more testing. Please write a simplest html page (without meta charset). Something like this: <html> <head> </head> <body> Hello! </body> </html> Then change encoding to big5 through menu encoding. If no problem happens, add a single chinese character. If still not, add more until it crashes. This way I will know if this is encoding related or conversion related. Shanno, could you post a stack whenever you got a debug build? Thanks! (My machine looks like the best one manufactured by HP for Netscape. :)
One more thing, please make sure that we are all talking about mozilla build instead of commercial one.
I was able to reproduce this bug on mozilla as well as commercial. Stack trace to follow.
shanjian, we only have the commercial optimize branch build put out by shannond (/u/shannond/BRANCH) no mozilla branch is available the simple html test (one single chinese chracter) fail when i select big5 through menu encoding, also if the menu encoding was set for auto-detect all, once it load the page it crashes.
Attached file console output before crash (deleted) —
Attached file stack trace (deleted) —
Attached file mozconfig options used to build (deleted) —
Thanks a lot shannon. I guess mCharsetInfo probably is null in nsFontMetricsGTK.h. But anyway, that is not the root of the problem. I will ask somebody in frank's group to take a look.
I finally reproduce the problem with exact mozconfig setting. (copied from an email sent to ftang and bstell) Though I am not exactly sure what the problem is, it seems related with recent checkin about special character handling for asian text. There is a preference setting "font.allow_double_byte_special_chars" to disable this feature, and the problem can not be seen after this option is set to "false" in prefs.js. I think we should make this default for HPUX. Since the problem does not exist in trunk, I hope the problem has been fixed in trunk. (Frank or brian, please let me know who is the person to implement this.) At this stage, I would suggest use preference setting to get around the problem, but make sure it get fixed in trunk. (Rob, shannon, What do you think? )
Which .mozconfig option was causing the problem?
I don't know. I don't have svg, mathml, and with_extension*
Attached patch patch that fixes this (deleted) — — Splinter Review
I posted a patch that fixes our problem on the branch. This is a combination of Brian Stell's patches for bug 16688 and bug 86368 that went into the trunk only. Don't know if this is the complete solution yet .. still need to completely read through these bugs. Looks like it was the mathml in the .mozconfig that caused this problem to show up. Jimmy, are any other Chinese sites that you saw crash before that we could test on now besides the one you listed? Thanks! Explanation for why this patch fixes the problem to follow (as soon as I read through the bugs I listed and try to understand, maybe Shanjian can explain better than I can)
Actually, every Chinese site would crash ~ try these http://kimo.comhttp://www.yam.com http://www.sina.com.tw
Attached patch smaller patch to fix this (deleted) — — Splinter Review
The only patch necessary was bstell's patch from bug 86368. All of the Chinese sites Jimmy listed work fine with this patch.
I was also looking into this problem this morning. The crash we experienced with Chinese websites has nothing to do with bug 16688. It is caused by the same bug as 86368, though the crash happens in different places. When font "adobe-symbol-*-adobe-fontspecific" is being load, mCharSetInfo is not correctly casted. This leads to crash when mCharSetInfo->convert is called. So shannon's patch is a good solution to this problem. (Patch 16688 is nice to have, but not necessary.) I also spotted another problem in patch for 33162, which is the one that implemented the feature I was talking about yesterday. That is the catalyst of the crash. That's say by disabling "font.allow_double_byte_special_chars" we are still able to avoid the crash. So it is a option for us if we do not want to change the code. (I will let bstell know the problem in 33162 and fix it in trunk.) Base on all the information we have, I believe checking in shannon's patch is a better option to this problem. I will reassign this bug to shannon no matter which option we choose.
Assignee: shanjian → shannond
Status: ASSIGNED → NEW
http://lxr.mozilla.org/seamonkey/source/gfx/src/gtk/nsFontMetricsGTK.cpp 3718 if (western_font) { 3719 NS_ASSERTION(western_font->SupportsChar(aChar), "font supposed to support this char"); 3720 return font; 3721 } The other problem I was talking about in my previous comment. In line 3720, western_font should be returned instead of font, which is nsnull in our testcase. That lead us to resort for "adobe-symbol-*-adobe-fontspecific". That font does not make any sense in our situation.
since we crash in HPUX. We may also crash in Solaris. What is our plan to take 86368?
*** Bug 91156 has been marked as a duplicate of this bug. ***
frank, what do you mean "plan for bug 86368"? The fix is already on trunk. Are you talking about fighting for branch? We would certainly like to see that happen.
I believe this is my bug
Assignee: shannond → bstell
Status: NEW → ASSIGNED
Brian, Rob Jaworski (my manager) got permission from pdt to check in this fix to branch after they tag the branch for RTM. Do you want to do this for us?
Yes, I can do the checkin.
I believe there are two parts to fix here: needs to be fixed in the 9.2 branch: ------------------------------------------ @@ -3025,8 +3098,10 @@ familyCharSetName.Append('-'); familyCharSetName.Append(charSetName); nsCStringKey familyCharSetKey(familyCharSetName); - charSetInfo = - (nsFontCharSetInfo*) gSpecialCharSets->Get(&familyCharSetKey); + charSetMap = NS_STATIC_CAST(nsFontCharSetMap*, gSpecialCharSets->Get(&familyCharSetKey)); + if (!charSetMap) + charSetMap = gNoneCharSetMap; + charSetInfo = charSetMap->mInfo; } if (!charSetInfo) { #ifdef NOISY_FONTS and needs to be fixed in both trunk (see bugs 86368, bug 33162) and branch: ----------------------------------------------------------------------- @@ -3717,7 +3717,7 @@ } if (western_font) { NS_ASSERTION(western_font->SupportsChar(aChar), "font supposed to support this char"); - return font; + return western_font; } else if (sub_font) { FIND_FONT_PRINTF((" transliterate special chars for single byte docs"));
This won't be getting into the 0.9.2 branch and since its fixed in the trunk by bug 86368 we can resolve this wontfix in the branch. Please see bug 86368 for any remaining issues.
the original bug was fixed. the patch to the patch will be fixed in bug 86368
Status: ASSIGNED → RESOLVED
Closed: 24 years ago
Resolution: --- → FIXED
jimmyu, can you verify this?
Verified with HPUX N6.1 Beta 2
Product: Browser → Seamonkey
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: