Crashes opening certain URLs

RESOLVED WORKSFORME

Status

()

Core
Layout
--
critical
RESOLVED WORKSFORME
15 years ago
13 years ago

People

(Reporter: Brian Hanks, Unassigned)

Tracking

({crash})

Trunk
x86
Linux
crash
Points:
---

Firefox Tracking Flags

(Not tracked)

Details

(URL)

Attachments

(1 attachment)

(Reporter)

Description

15 years ago
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

15 years ago
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.
.
Assignee: ccarlen → blizzard
Component: Profile Manager BackEnd → Embedding: GTK Widget
QA Contact: gbush → pavlov

Comment 3

15 years ago
worksforme with linux trunk 20030726.
Severity: normal → critical
Keywords: crash

Comment 4

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

Comment 5

15 years ago
It works fine for me on 1.5 Alpha: build ID 2003071814. 
Working here.  Do you have a stack trace or something similar?
(Reporter)

Comment 7

15 years ago
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

15 years ago
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
Assignee: blizzard → other
Component: Embedding: GTK Widget → Layout
QA Contact: pavlov → ian
(Reporter)

Comment 9

15 years ago
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

15 years ago
> 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"?
Blocks: 198955
(Reporter)

Comment 11

15 years ago
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.  
(Reporter)

Comment 12

15 years ago
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

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

Comment 14

15 years ago
Created attachment 129151 [details]
Galeon Stack Trace from Attachment 106795 [details]

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

Comment 15

13 years ago
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.
(Reporter)

Comment 16

13 years ago
No longer an issue. This was fixed a while back.
Status: UNCONFIRMED → RESOLVED
Last Resolved: 13 years ago
Resolution: --- → FIXED

Comment 17

13 years ago
No specific bug / patch referenced as the fix.

-> WORKSFORME
Status: RESOLVED → UNCONFIRMED
Resolution: FIXED → ---

Updated

13 years ago
Status: UNCONFIRMED → RESOLVED
Last Resolved: 13 years ago13 years ago
Resolution: --- → WORKSFORME
You need to log in before you can comment on or make changes to this bug.