214147 - Crashes opening certain URLs

Status: RESOLVED WORKSFORME

(Core :: Layout, defect)

Description

[Brian Hanks]

User-Agent:       Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.4) Gecko/20030618
Build Identifier: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.4) Gecko/20030618

Simply open the above URL and broser (galeon 1.3.5 & 1.3.7) will crash. 
Originally reported as a galeon bug.  Was told to report here instead.

Reproducible: Always

Steps to Reproduce:
1.  Open galeon or mozilla.
2.  Open http://cl.com.com/Click?q=ae-jOB6QMBAEYct26qiXL_f1dpED9RR in a second tab.

Actual Results:  
Browser application crashed.

Expected Results:  
Opened the URL without error.

Seems to be many zdnet & msn sites that cause the problem.

See original report at http://bugzilla.gnome.org/show_bug.cgi?id=118385

Comment 1

[Glenn Morse]

Using Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.5b) Gecko/20030727, page loads fine, although extremely slowly :) Can you reproduce this on a recent nightly of Mozilla? This would help to determine if this is actually a Mozilla bug, and not something Galeon-specific.

Comment 2

[Matthias Versen [:Matti]]

.

Comment 3

[Andrew Schultz]

worksforme with linux trunk 20030726.

Comment 4

[Mihail Daskalov]

works for me
Mozilla 1.5alpha (build 2003071814) on Windows 2000

Comment 5

[Mary Y.]

It works fine for me on 1.5 Alpha: build ID 2003071814. 

Comment 6

[Christopher Blizzard (:blizzard)]

Working here.  Do you have a stack trace or something similar?

Comment 7

[Brian Hanks]

The information that I saved from the original report as a galeon bug is still
available at http://bugzilla.gnome.org/show_bug.cgi?id=118385 

Beyond that you will have to excuse my ingnorance.  I'm not sure exactly where
the stack trace would get written to during the crash.  I can still create the
issue at will, so more info is probably available.

Comment 8

[Andrew Schultz]

the stacktrace in the gnome bug shows a crash "in
nsProfileLock::FatalSignalHandler(int) from gtkmozembed.so", but I would guess
that's red herring since that is just the signal handler.  The crash occured
below that in the stack.

the crash actually occured in gklayout.so

Brian: the stack you provided is from a stripped build of Galeon.  Can you
provide a stacktrace from a Mozilla build that isn't stripped (RPM would not be
stripped) or a talkback ID from an installer build?

also, are you using xft-enabled builds?  probable dupe of bug 180309
(http://reviews-zdnet.com.com/css/all.css refers to font "ms sans serif")

==> layout

Comment 9

[Brian Hanks]

When I open it in Mozilla, it just crashes without any discernable type of error
trapping.  Where can I look for a stack trace?

Also, how do I determine if I'm using xft-enabled builds?  I'm guessing that I
am given that I'm using a fully patched RedHat 9 system with the following packages:
mozilla-dom-inspector-1.4-8
mozilla-mail-1.4-8
mozilla-nspr-1.4-8
mozilla-chat-1.4-8
mozilla-nspr-devel-1.4-8
mozilla-1.4-8
mozilla-devel-1.4-8
mozilla-nss-devel-1.4-8
mozilla-nss-1.4-8
mozilla-psm-1.4-8
mozilla-js-debugger-1.4-8
galeon-debuginfo-1.3.5-1
galeon-1.3.7-1

Comment 10

[Andrew Schultz]

> mozilla-1.4-8

is this from Red Hat Rawhide?
RPMs from .mozilla.org are 1.4-0.  Red Hat 9 came with 1.2.1

do you have any .fon (MS fonts) in your font path?

try typing "about:buildconfig" into the URL bar.  do the "configure arguments"
include "--enable-xft"?

Comment 11

[Brian Hanks]

The "configure arguments" do include "--enable-xft".  

Yes, the mozilla package is a RedHat rawhide package.  When the original crash
popped up with older versions of galeon and mozilla (don't recall which, it has
been a while), I reported it as a galeon bug.  I was told to upgrade to the
latest version of galeon which required a more recent version of mozilla.  I
pulled the galeon package from galeon.sourceforge.net and the mozilla packages
from rpmfind.net.

Yes, there are *.fon files in the fontpath.  

Comment 12

[Brian Hanks]

I removed the directories associated with *.fon files from the font path. 
Restarted xfs and used chkfontpath to verify that they were gone.  Both galeon
and mozilla are still crashing.

Comment 13

[Andrew Schultz]

do you crash with attachment 106795 [details] from bug 180309 (with the .fon files removed
from your font path)?

Comment 14

[Brian Hanks]

Attachment: Galeon Stack Trace from Attachment 106795

This is the stack trace generated when attempting to open attachment 106795 [details] in
galeon without *.fon files in the fontpath.

Comment 15

[Andrew Schultz]

Brian: is this still a problem with a recent build (1.7 or 1.8b)?  Most of the
problems like this bug have been fixed.

Comment 16

[Brian Hanks]

No longer an issue. This was fixed a while back.

Comment 17

[Jason Bassford]

No specific bug / patch referenced as the fix.

-> WORKSFORME