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
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
worksforme with linux trunk 20030726.
Severity: normal → critical
works for me Mozilla 1.5alpha (build 2003071814) on Windows 2000
It works fine for me on 1.5 Alpha: build ID 2003071814.
Working here. Do you have a stack trace or something similar?
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.
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
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
> 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"?
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.
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.
do you crash with attachment 106795 [details] from bug 180309 (with the .fon files removed from your font path)?
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.
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.
No longer an issue. This was fixed a while back.
Status: UNCONFIRMED → RESOLVED
Last Resolved: 13 years ago
Resolution: --- → FIXED
No specific bug / patch referenced as the fix. -> WORKSFORME
Status: RESOLVED → UNCONFIRMED
Resolution: FIXED → ---
Status: UNCONFIRMED → RESOLVED
Last Resolved: 13 years ago → 13 years ago
Resolution: --- → WORKSFORME
You need to log in before you can comment on or make changes to this bug.