Closed
Bug 85059
Opened 23 years ago
Closed 23 years ago
crash on attempting to load this URL
Categories
(Core :: Internationalization, defect)
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)
(deleted),
text/html
|
Details | |
(deleted),
patch
|
Details | Diff | Splinter Review | |
(deleted),
patch
|
Details | Diff | Splinter Review | |
(deleted),
patch
|
Details | Diff | Splinter Review |
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
Comment 2•23 years ago
|
||
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.
Comment 4•23 years ago
|
||
Mozilla 0.9.1 on macintosh has no problem with that URL.
Comment 5•23 years ago
|
||
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.
Comment 6•23 years ago
|
||
WFM 2001061108 Linux
Reporter | ||
Comment 8•23 years ago
|
||
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.
Reporter | ||
Comment 9•23 years ago
|
||
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
Comment 10•23 years ago
|
||
could you load the talkback program and retrieve the talkback id for us?
Reporter | ||
Comment 11•23 years ago
|
||
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
Comment 12•23 years ago
|
||
Doesn't crash for me with Linux 0.9.1, but I did noticed a lot of disk activity.
Comment 13•23 years ago
|
||
WFM with linux cvs build from today, running in gdb.
Comment 14•23 years ago
|
||
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.
Comment 15•23 years ago
|
||
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
Comment 16•23 years ago
|
||
think this is layout code..
Assignee: asa → karnaze
Component: Browser-General → Layout
QA Contact: doronr → petersen
Reporter | ||
Comment 17•23 years ago
|
||
Thanks Asa.
Talkback IDs are:
TB31629949M and TB31610847G
same bug, 2 different talkback submissions.
cheers all,
Phil
Comment 18•23 years ago
|
||
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.
Comment 19•23 years ago
|
||
Could you please try some recent build? WFM with 2001061914 also when trying to
browse around the whole site.
Reporter | ||
Comment 20•23 years ago
|
||
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
Comment 21•23 years ago
|
||
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?
Comment 22•23 years ago
|
||
this code is crashing mozilla on linux:
<html>
<head>
<meta http-equiv=Content-Type content="text/html; charset=x-user-defined">
</head>
<body>
©
</body>
</html>
note the content value and the char to be displayed ©
Comment 23•23 years ago
|
||
Updated•23 years ago
|
Assignee: karnaze → rchen
Component: Layout → Localization
QA Contact: petersen → andreasb
Comment 24•23 years ago
|
||
reassigned to Localization
Comment 25•23 years ago
|
||
This should go to internationalization instead of localization. CC ftang.
Assignee: rchen → nhotta
Component: Localization → Internationalization
QA Contact: ylong → andreasb
Updated•23 years ago
|
QA Contact: andreasb → ylong
Comment 26•23 years ago
|
||
The attachment (and the Inquirer too) is WFM linux 2001062421.
Updated•23 years ago
|
Keywords: stackneeded
Comment 28•23 years ago
|
||
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.
Comment 29•23 years ago
|
||
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).
Comment 30•23 years ago
|
||
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
Comment 31•23 years ago
|
||
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
Comment 32•23 years ago
|
||
BStell - Pls assign TM and priority.
Comment 34•23 years ago
|
||
owner: this bug is a dup of 81359
please see who has to solve
the problem and mark as dup
Assignee | ||
Comment 35•23 years ago
|
||
If I comment out the code checked in for bug 81528 the crash stops.
Status: NEW → ASSIGNED
Assignee | ||
Comment 36•23 years ago
|
||
Assignee | ||
Comment 37•23 years ago
|
||
*** Bug 81359 has been marked as a duplicate of this bug. ***
Comment 38•23 years ago
|
||
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
Assignee | ||
Comment 39•23 years ago
|
||
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.
Updated•23 years ago
|
Whiteboard: patch ready, r=ftang, need sr=
Comment 41•23 years ago
|
||
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..
Assignee | ||
Comment 42•23 years ago
|
||
Comment 43•23 years ago
|
||
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
Comment 44•23 years ago
|
||
Comment 45•23 years ago
|
||
cool, thanks... sr=alecf
Assignee | ||
Comment 46•23 years ago
|
||
checked into branch
Assignee | ||
Comment 47•23 years ago
|
||
checked into trunk
Status: ASSIGNED → RESOLVED
Closed: 23 years ago
Resolution: --- → FIXED
Assignee | ||
Comment 48•23 years ago
|
||
reopen so we can get a fix for the bustage in the ports (other OSs)
Status: RESOLVED → REOPENED
Resolution: FIXED → ---
Assignee | ||
Updated•23 years ago
|
Status: REOPENED → ASSIGNED
Whiteboard: patch ready, r=ftang, need sr= → patch ready, r=ftang, sr=alecf, need PDT+
Comment 49•23 years ago
|
||
Comment 50•23 years ago
|
||
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++) {
^
Assignee | ||
Comment 51•23 years ago
|
||
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
>
Assignee | ||
Comment 52•23 years ago
|
||
bustage fix checked into branch
Status: ASSIGNED → RESOLVED
Closed: 23 years ago → 23 years ago
Resolution: --- → FIXED
Comment 53•23 years ago
|
||
I filed bug 90049 for the incorrect displaying of the copyright symbol.
Comment 55•23 years ago
|
||
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 → ---
Updated•23 years ago
|
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
Comment 56•23 years ago
|
||
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 ago → 23 years ago
Resolution: --- → FIXED
Assignee | ||
Updated•23 years ago
|
Whiteboard: [PDT+ ] patch ready, r=ftang, sr=alecf
Comment 57•23 years ago
|
||
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.
Description
•