Closed
Bug 235198
Opened 20 years ago
Closed 20 years ago
crashes the browser
Categories
(Firefox :: General, defect)
Tracking
()
RESOLVED
DUPLICATE
of bug 180309
People
(Reporter: davech, Assigned: bugzilla)
References
()
Details
(Keywords: crash)
Attachments
(2 files)
User-Agent: Build Identifier: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.6) Gecko/20040207 Firefox/0.8 This pages crashes the browser while loading The page loads ok in Firebird 0.7 and netscape communicator 4.8 Reproducible: Always Steps to Reproduce: 1. start browser 2. load page 3. Actual Results: browser crashes Expected Results: load page Sorry I don't have access to the module in which the software crashed
|
||
Comment 1•20 years ago
|
||
WFM: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7a) Gecko/20040220 Firefox/0.8.0+
|
Reporter | |
Comment 2•20 years ago
|
||
Same problem with the home page: http://techupdate.zdnet.com
|
||
Comment 3•20 years ago
|
||
Also works fine for me on OS X, 20040216 Firefox/0.8.0+ Perhaps it's a Linux-specific problem, but David, could you please try out the following possibilities: - Do you have any browser extensions installed? If so, try disabling them and see if that fixes it. or: - Do you have any browser themes installed (other than the one that comes packaged with Firefox)? If so, try disabling them and see if that fixes it. or: - It's possible your user profile has been corrupted between versions. Please try starting Firefox with a fresh profile: either trash your old profile (temporarily at least), or start the profile manager (see: http://texturizer.net/firebird/faq.html#profilemanager). Your user profile is likely to be found in C:\Documents and Settings\<your user name>\Application Data\Phoenix\ Please let us know whether or not any of those things fix it. cheers
|
|
Reporter | |
Comment 4•20 years ago
|
||
I tried moving the .phoenix directory out of the way so that firefox would create a new one. That doesn't solve the problem
|
|
||
Comment 5•20 years ago
|
||
Any browser themes or extensions, though?
|
|
Reporter | |
Comment 6•20 years ago
|
||
No themes, no extensions
|
||
Comment 7•20 years ago
|
||
WFM on Linux, Firefox current trunk build (gtk2 + xft). Is your build gtk2+xft or just x11core (perhaps, labelled as 'gtk' build)? Can you see if 'enable-xft' is listed in the output of 'about:buildconfig' (type that in the location bar)?
|
|
Reporter | |
Comment 8•20 years ago
|
||
Configure arguments --disable-ldap --disable-mailnews --enable-extensions=cookie,xml-rpc,xmlextras,p3p,pref,transformiix,universalchardet,typeaheadfind,webservices,inspector --enable-crypto --disable-composer --disable-debug '--enable-optimize=-Os -g' --disable-tests --enable-default-toolkit=gtk2 --enable-xft --enable-static --disable-shared
|
|
Reporter | |
Comment 9•20 years ago
|
||
I just realised firefox was compiled with '-g'. Here's the gdb output: Program received signal SIGSEGV, Segmentation fault. [Switching to Thread 16384 (LWP 7849)] 0x08455d45 in nsSharedBufferHandle<unsigned short>*NS_AllocateContiguousHandleWithData<nsSharedBufferHandle<unsigned short>,nsAString>(nsSharedBufferHandle<unsigned short> const*, unsigned, nsAString const*) ()
|
|
||
Comment 10•20 years ago
|
||
So, your build is gtk2 + xft (0.8). I don't have a problem with a gtk2+xft (trunk build). Can you attach a stack backtrace (just one frame doesn't help much) ? In gdb, you can attach to the firefox process and type 'bt' in gdb to get the stack trace once firefox crashes.
|
|
Reporter | |
Comment 11•20 years ago
|
||
Here's the gdb backtrace
|
|
Reporter | |
Comment 12•20 years ago
|
||
I've reduced the problem to these two short files which trigger the crash:
bar.html:
--------------
<html>
<head>
<link rel="stylesheet" type="text/css" href="file://localhost/home/dc/bad.css" />
</head>
<body>
<span class="problem">asdf</span>
</body>
</html>
---------------
bad.css:
--------------
.problem
{font-family: ms sans serif; }
--------------
Looks like it might be a bug in one of the shared font libraries
|
|
||
Comment 13•20 years ago
|
||
Thanks for the stack trace and the reduced test case. Can you try (at the shell prompt) $ fc-list 'ms sans serif' family file BTW, what happens if your enclose 'ms sans serif' with quotation marks in your style sheet? According to the stack, there may be something wrong with our allocators. We may have fixed it rencently. David, can you try a recent nightly build (gtk2 + xft)?
|
|
Reporter | |
Comment 14•20 years ago
|
||
$ fc-list 'ms sans serif' family file /usr/share/fonts/truetype/winfonts/sserife.fon: MS Sans Serif /usr/share/fonts/truetype/winfonts/sseriff.fon: MS Sans Serif /win0/winnt/Fonts/sseriffe.fon: MS Sans Serif /win0/winnt/Fonts/sserifee.fon: MS Sans Serif /win0/winnt/Fonts/sserife.fon: MS Sans Serif /win0/winnt/Fonts/sseriff.fon: MS Sans Serif /usr/share/fonts/truetype/winfonts/sserifee.fon: MS Sans Serif /usr/share/fonts/truetype/winfonts/sseriffe.fon: MS Sans Serif Enclosing 'ms sans serif' with quotation marks in the style sheet makes no difference. With Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7b) Gecko/20040223 Firefox/0.8.0+ I get a different stack trace: Program received signal SIGSEGV, Segmentation fault. [Switching to Thread 16384 (LWP 2079)] 0x084392ba in nsPRUint32Key::Clone() const () (gdb) bt #0 0x084392ba in nsPRUint32Key::Clone() const () #1 0x084320b4 in nsPRUint32Key::Clone() const () #2 0x084146ec in nsPRUint32Key::Clone() const () #3 0x08414604 in nsPRUint32Key::Clone() const () #4 0x0841af84 in nsPRUint32Key::Clone() const () #5 0x0841f58d in nsPRUint32Key::Clone() const () #6 0x084146ec in nsPRUint32Key::Clone() const () #7 0x0840f1a9 in nsPRUint32Key::Clone() const () #8 0x0841af84 in nsPRUint32Key::Clone() const () #9 0x0840f066 in nsPRUint32Key::Clone() const () #10 0x084146ec in nsPRUint32Key::Clone() const () #11 0x0840f1a9 in nsPRUint32Key::Clone() const () #12 0x0841af84 in nsPRUint32Key::Clone() const () #13 0x0840f066 in nsPRUint32Key::Clone() const () #14 0x084146ec in nsPRUint32Key::Clone() const () #15 0x08414604 in nsPRUint32Key::Clone() const () #16 0x0841ae47 in nsPRUint32Key::Clone() const () #17 0x0841b979 in nsPRUint32Key::Clone() const () #18 0x08259cb7 in nsReadingIterator<unsigned short>::advance(int) () #19 0x083b89be in nsPRUint32Key::Clone() const () #20 0x083bcde6 in nsPRUint32Key::Clone() const () #21 0x083bc887 in nsPRUint32Key::Clone() const () #22 0x083bba13 in nsPRUint32Key::Clone() const () #23 0x083bd8c9 in nsPRUint32Key::Clone() const () #24 0x083b8416 in nsPRUint32Key::Clone() const () #25 0x0823f251 in nsReadingIterator<unsigned short>::advance(int) () #26 0x08239757 in nsReadingIterator<unsigned short>::advance(int) () #27 0x0823cf0a in nsReadingIterator<unsigned short>::advance(int) () #28 0x4030acd4 in _gtk_marshal_BOOLEAN__BOXED () from /usr/local/gnome/lib/libgtk-x11-2.0.so.0 #29 0x08b08ce8 in ?? () #30 0xbfffd86c in ?? ()
|
|
||
Comment 15•20 years ago
|
||
Removing 'ms sans serif' (Windows 'fon' font) would solve your problem. While you're at it, why don't get all 'fon' fonts out of the fontconfig font search path? Truetype fonts work very well, but 'fon' fonts are not supported by freetype/Xft as far as I know. See bug 183729 Howver, your stack is very curious....
|
|
Reporter | |
Comment 16•20 years ago
|
||
Removing the .fon files from the fontconfig path does solve the problem. But I would still consider it a bug for firefox to crash on them. If freetype/Xft doesn't support .fon fonts it shouldn't be trying to load them
|
|
||
Comment 17•20 years ago
|
||
Well, it's not Mozilla but fontconfig/Xft that 'advertises' its availability. Mozilla doesn't know the font type at all. There's a bug filed on http://bugzilla.freedesktop.org for font-type ID APIs.. I'd have duped this if the stack were similar to what we have in bug 183729, but it's markedly different so that I'm keeping this open.
|
||
Comment 18•20 years ago
|
||
(In reply to comment #9) > I just realised firefox was compiled with '-g'. Here's the gdb output: > > Program received signal SIGSEGV, Segmentation fault. > [Switching to Thread 16384 (LWP 7849)] > 0x08455d45 in nsSharedBufferHandle<unsigned > short>*NS_AllocateContiguousHandleWithData<nsSharedBufferHandle<unsigned > short>,nsAString>(nsSharedBufferHandle<unsigned short> const*, unsigned, > nsAString const*) () can anyone reproduce this with a more recent trunk build? the code referenced in this stack trace no longer exists (since about 2/19). it'd be helpful if someone could test and generate a new stack trace if the problem persists.
|
|
||
Comment 19•20 years ago
|
||
With my build (my tree is almost up to date) on fedora core1 (freetype 2.1.5?, Xft/fontconfig perhaps about a month old), I can't reproduce the crash even with 'fon' fonts present. As I wrote in comment #13, darin's string changes may have fixed the problem. Googling 'fon' and 'Windows bitmap xft freetype' turned up hits that indicate that 'fon' fonts are supported. So, I was wrong, but I certainly remember there was a bug with 'fon' font and Mozilla crashing that I can't find any more. (it's not bug 183729.) David, can you try a nightly build (gtk2 + xft) and see if you can reproduce the crash ?
|
|
Reporter | |
Comment 20•20 years ago
|
||
> David, can you try a nightly build (gtk2 + xft) and see if you can reproduce the > crash ? I did (comment #14)
|
|
||
Comment 21•20 years ago
|
||
David, sorry I missed it. Darin, any idea about the stack trace in comment #14 (taken with a 2004 02 23 build) ?
|
|
||
Comment 22•20 years ago
|
||
no, that stack trace really doesn't make much sense to me. In fact, all of those symbol names are names corresponding to inline functions. I think that stack trace (in comment #14) is bogus/useless. was that actually a debug build? the UA string suggests it's a nightly off of ftp.mozilla.org, no?
|
|
||
Comment 23•20 years ago
|
||
Yeah, I think David tried a nightly (per my suggestion) which is an optimized build with '-g' (I hoped that would be enough). David, can you build a debug build (no optimization) and get a stack trace?
|
|
Reporter | |
Comment 24•20 years ago
|
||
Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7b) Gecko/20040225 Firefox/0.8.0+ from CVS compiled with debugging. This is with the .fon fonts in the font path. If I take them out it works.
|
|
||
Comment 25•20 years ago
|
||
Updating to the newest version of fontconfig should fix your problem. My fontconfig is up to date, which is why I don't have a problem with 'FON' fonts. *** This bug has been marked as a duplicate of 180309 ***
Status: UNCONFIRMED → RESOLVED
Closed: 20 years ago
Resolution: --- → DUPLICATE
You need to log in
before you can comment on or make changes to this bug.
Description
•