Closed Bug 85059 Opened 23 years ago Closed 23 years ago

crash on attempting to load this URL

Categories

(Core :: Internationalization, defect)

x86
Linux
defect
Not set
critical

Tracking

()

VERIFIED FIXED
mozilla0.9.3

People

(Reporter: phil, Assigned: bstell)

References

()

Details

(Keywords: crash, intl, Whiteboard: [PDT+ ] patch ready, r=ftang, sr=alecf)

Attachments

(4 files)

From Bugzilla Helper: User-Agent: Mozilla/5.0 (X11; U; Linux 2.4.5 i586; en-US; rv:0.9.1) Gecko/20010607 BuildID: 2001060713 Mozilla crashes trying to load the URL http://www.theinquirer.net/10060106.htm Reproducible: Always Steps to Reproduce: 1.Go to URL 2. See Moz crash :) Actual Results: shell reports: Error loading URL http://www.theinquirer.net/10060106.htm : 2152398850 Segmentation fault
WFM using 2001060820 Win2k. Maybe a Linux only bug.
Keywords: crash
WFM 2001060713 linux
Didn't crash with a 0.9.1 build, 2001060905 linux either, but something is strange there: During load there was an unusual amount of disk activity. Page froze for a little while. I thought it contained java but it doesn't seem to. Then did a "view source", but the result seemed incomplete so i dismissed it. Tried view source again, and mozilla froze using 99% CPU for a over a minute. Then things rendered again. The source was still incomplete.
Mozilla 0.9.1 on macintosh has no problem with that URL.
If you liked this bug, you might also enjoy bug 85082 - the reporters there have a theory that theinquirer.net using a copyright symbol is what is crashing your linux browsers. Again, no problems with Mac OS or Windows for that bug either.
WFM 2001061108 Linux
We need a stacktrace or a talkback id from the crash.
Keywords: stackneeded
I don't see a core dump (Yes, I've set the coredumpsize to unlimited with ulimit -c unlimited). Just a segfault; that's it.
OK I installed talkback.xpi and got the crash again and let the fullcircle thingy submit the data. I put the same URL in again. Hope that's sufficient
could you load the talkback program and retrieve the talkback id for us?
I'm a bit new at all this. After mozilla crashes, I get the talkback window, I press "send" and the window goes away. I don't see a talkback id anywhere (I went through the "Details" of the talkback to look). How do I invoke the talkback program directly? Incidentally, this bug shows remarkable similarities with bug #81359
Doesn't crash for me with Linux 0.9.1, but I did noticed a lot of disk activity.
WFM with linux cvs build from today, running in gdb.
Philip Armstrong, to get the talkback incident IDs you need to launch the talkback client manually. The talkback client lives in the /<install dir>/components/talkback directory. ./talback from there brings it up for me. You can set the Settings|Options|Incident Sending Settings to "Immediately after I select Send" instead of "Automatic" and it should leave the talkback window open next time you get a crash and press the send incident button. If you could check this and post the ID to this bug tht would be very helpful. Also if you include your bugzilla email in the email field of the incident report I can look it up by that.
Incident ID 31629949 Stack Signature nsRenderingContextGTK::DrawString() ccaa8240 Bug ID Trigger Time 2001-06-12 10:29:59 User Comments Build ID 2001060713 Product ID Netscape6.10B1 Platform ID LinuxIntel Stack Trace nsRenderingContextGTK::DrawString() nsTextFrame::PaintUnicodeText() nsTextFrame::Paint() nsContainerFrame::PaintChild() nsContainerFrame::PaintChildren() nsHTMLContainerFrame::Paint() nsContainerFrame::PaintChild() nsContainerFrame::PaintChildren() nsHTMLContainerFrame::Paint() nsContainerFrame::PaintChild() nsBlockFrame::PaintChildren() nsBlockFrame::Paint() nsContainerFrame::PaintChild() nsBlockFrame::PaintChildren() nsBlockFrame::Paint() nsContainerFrame::PaintChild() nsContainerFrame::PaintChildren() nsTableCellFrame::Paint() nsTableRowFrame::PaintChildren() nsTableRowFrame::Paint() nsTableRowGroupFrame::PaintChildren() nsTableRowGroupFrame::Paint() nsContainerFrame::PaintChild() nsContainerFrame::PaintChildren() nsTableFrame::Paint() nsContainerFrame::PaintChild() nsTableOuterFrame::Paint() nsContainerFrame::PaintChild() nsBlockFrame::PaintChildren() nsBlockFrame::Paint() nsContainerFrame::PaintChild() nsBlockFrame::PaintChildren() nsBlockFrame::Paint() nsContainerFrame::PaintChild() nsContainerFrame::PaintChildren() nsHTMLContainerFrame::Paint() CanvasFrame::Paint() PresShell::Paint() nsView::Paint() nsViewManager::RenderDisplayListElement() nsViewManager::RenderViews() nsViewManager::Refresh() nsViewManager::DispatchEvent() HandleEvent() nsWidget::DispatchEvent() nsWidget::DispatchWindowEvent() nsWindow::DoPaint() nsWindow::Update() nsWindow::Update() nsWindow::UpdateIdle() libglib-1.2.so.0 + 0x1134a (0x4035734a) libglib-1.2.so.0 + 0x10328 (0x40356328) libglib-1.2.so.0 + 0x10933 (0x40356933) libglib-1.2.so.0 + 0x10acc (0x40356acc) libgtk-1.2.so.0 + 0x8d667 (0x40277667) nsAppShell::Run() nsAppShellService::Run() main1() main() libc.so.6 + 0x1d38b (0x4049238b) and incident 31610847 on the same day looks the same.
Status: UNCONFIRMED → NEW
Ever confirmed: true
think this is layout code..
Assignee: asa → karnaze
Component: Browser-General → Layout
QA Contact: doronr → petersen
Thanks Asa. Talkback IDs are: TB31629949M and TB31610847G same bug, 2 different talkback submissions. cheers all, Phil
I filed bug 81359 which probably is the same issue as this. I still see the issue; I have filed a talkback report referred to in that bug.
Could you please try some recent build? WFM with 2001061914 also when trying to browse around the whole site.
OK BuildId: 2001061910 No crash on loading the page, but I do get Error loading URL http://www.theinquirer.net/10060106.htm : 2152398850 on the command line. The page appears to display ok otherwise
I see the crash on linux with build 2001062309, but not with 0.9.1. This must be the same issue as bug 81359, shouldn't we mark this as a duplicate?
this code is crashing mozilla on linux: <html> <head> <meta http-equiv=Content-Type content="text/html; charset=x-user-defined"> </head> <body> &copy; </body> </html> note the content value and the char to be displayed &copy;
Assignee: karnaze → rchen
Component: Layout → Localization
QA Contact: petersen → andreasb
reassigned to Localization
Keywords: intl
QA Contact: andreasb → ylong
This should go to internationalization instead of localization. CC ftang.
Assignee: rchen → nhotta
Component: Localization → Internationalization
QA Contact: ylong → andreasb
QA Contact: andreasb → ylong
The attachment (and the Inquirer too) is WFM linux 2001062421.
Reassign to bstell. IQA, is this reproducible?
Assignee: nhotta → bstell
Keywords: stackneeded
I can reproduce the crash with 06-27-06-0.9.2 build when loading the attached HTML file. It doesn't crash on Windows and Mac.
On 06-25 Linux Branch build / RedHad6.2-Ja: It didn't crash when I first load this page by typing into URL bar, but it crash when I reload (Talkback ID 32244937).
The charset meta tag in the attached html is x-user-defined. It doesn't crash if I change the charset meta tag to iso-8859-1/euc-jp/x-sjis
OK, seems if I add "User Defined" charset will get a crash (Talk back ID 32246534): 1. Launch browser and go: http://home.netscape.com 2. View | Character Coding | Customize 3. Choose "User Defined" and add it. 4. Click "User Defined" charset by going View | Character Coding | User Defined Then yo will see the crash
BStell - Pls assign TM and priority.
adding nsbranch
Keywords: nsBranch
owner: this bug is a dup of 81359 please see who has to solve the problem and mark as dup
If I comment out the code checked in for bug 81528 the crash stops.
Status: NEW → ASSIGNED
*** Bug 81359 has been marked as a duplicate of this bug. ***
Linux, build 2001062706 I do not crash on the testcase, the copyright symbol is rendered as (c) however. I do crash on the URL as well as on other URLS given in bug 81359. Talkback IDs are TB32275498X TB32275439G TB32275377K Adding 4xp keyword because of misrendering. Should I file the copyright symbol problem as a separate bug?
Keywords: 4xp
could be that crashing on the copyright symbol depends on the fonts available on a given system. If this patch fixes the copyright problem then we probably do not need to open a separate bug.
r=ftang got sr please.
Target Milestone: --- → mozilla0.9.3
Whiteboard: patch ready, r=ftang, need sr=
is that empty glyph going to be looked at in any way? because it doesn't look like it's initialized :( Seems like on some unix platforms you might get garbage in that variable..
PDT+ per pdt meeting. Check it in to both branch and trunk while you are ready.
Summary: crash on attempting to load this URL → PDT+ crash on attempting to load this URL
cool, thanks... sr=alecf
checked into branch
checked into trunk
Status: ASSIGNED → RESOLVED
Closed: 23 years ago
Resolution: --- → FIXED
reopen so we can get a fix for the bustage in the ports (other OSs)
Status: RESOLVED → REOPENED
Resolution: FIXED → ---
Status: REOPENED → ASSIGNED
Whiteboard: patch ready, r=ftang, need sr= → patch ready, r=ftang, sr=alecf, need PDT+
I've attached a fix that jaggernaut checked into the trunk that fixed a redefined symbol in nsFontMetricsGTK.cpp. This is a problem for some compilers. The error on HP-UX: Error 173: "nsFontMetricsGTK.cpp", line 799 # Redefined symbol 'i'; previously defined at ["nsFontMetricsGTK.cpp", line 790]. for (int i=0; gDoubleByteSpecialChars[i]; i++) { ^
from email: ---------------------------------------------------------------- Subject: Re: pls PDT+ bustage fix for bug 85059 Date: Mon, 02 Jul 2001 11:58:50 -0700 From: chofmann@netscape.com (Chris Hofmann) To: Brian Stell <bstell@netscape.com> CC: pdt2 <pdt2@netscape.com>, Yung-Fong Tang <ftang@netscape.com>, Shannon Diener <shannond@netscape.com> References: 1 a=chofmann Brian Stell wrote: >PDT, > >Please PDT+ a patch to fix compile bustage in the ports on the branch. > > http://bonsai.mozilla.org/cvsview2.cgi?diff_mode=context&whitespace_mode=show&fi le=nsFontMetricsGTK.cpp&root=/cvsroot&subdir=mozilla/gfx/src/gtk&command=DIFF_FR AMESET&rev1=1.157&rev2=1.158 > >Brian >
bustage fix checked into branch
Status: ASSIGNED → RESOLVED
Closed: 23 years ago23 years ago
Resolution: --- → FIXED
I filed bug 90049 for the incorrect displaying of the copyright symbol.
Fixed verified on 07-13 branch build.
Status: RESOLVED → VERIFIED
I just saw something related to this bug in Mozilla news. I tried to reply to a news posting that used the encoding "x-user-defined". When I typed a non-ASCII character the computer froze for a while (I thought it had crashed), and started a lot of disc activity (a lot!). When I got control back, the character I had typed materialized in the form of a surrogate ASCII sequence: a c with a circumflex had become "c^" (two characters). From then on, in that reply window, all such characters - that I normally type without a problem in Mozilla - became such surrogate ASCII combinations. If I change the encoding for such a message _before I hit "reply"_, this weird behaviour does not happen. But changing the encoding when the reply window is already open does not help. So this is not about the copyright symbol, but about a lot of characters that are in this (undocumented?) table of ASCII surrogates (I've seen it used sometimes when copying from Mozilla into non-Unicode-aware applications).
Status: VERIFIED → REOPENED
Resolution: FIXED → ---
Summary: PDT+ crash on attempting to load this URL → crash on attempting to load this URL
Whiteboard: patch ready, r=ftang, sr=alecf, need PDT+ → [PDT+ ] patch ready, r=ftang, sr=alecf
Bertilo, this is surely a valid bugreport, but does it fall under the title "crash on attempting to load this URL"? I think not. Let this bug rest in peace. I will cut and paste your comment to bug 90049, feel free to open a new bug if you think that bug does not cover the issue. --> FIXED (again - or rather still)
Status: REOPENED → RESOLVED
Closed: 23 years ago23 years ago
Resolution: --- → FIXED
Whiteboard: [PDT+ ] patch ready, r=ftang, sr=alecf
Marking as verified per previous comments, also it's not the case of orginal crash problem.
Status: RESOLVED → VERIFIED
Whiteboard: [PDT+ ] patch ready, r=ftang, sr=alecf
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Created:
Updated:
Size: