Closed
Bug 136362
Opened 23 years ago
Closed 14 years ago
using Xinerama and Xfs can hang the browser
Categories
(Core :: Internationalization, defect)
Tracking
()
RESOLVED
INVALID
People
(Reporter: kika, Assigned: smontagu)
References
Details
(Keywords: hang, intl, Whiteboard: INVALID)
Attachments
(5 files)
From Bugzilla Helper:
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:0.9.9) Gecko/20020310
BuildID: 2002031008
Browser hangs forever while trying to display this document. Document arrived in
mail, Mail hung also. Nothing is displayed, progress bar freezes halfway.
Reproducible: Always
Steps to Reproduce:
1.Load the document via File->Open File.
2.
3.
Actual Results: Hang
Expected Results: Display the page, I suppose.
<html>
<head>
<META HTTP-EQUIV="Content-Type" CONTENT="text/html; charset=Windows-1251">
<title>EXIST хМРЕПМЕР-ЛЮЦЮГХМ ЮБРНГЮОВЮЯРЕИ</title>
</head>
<body leftmargin=0 topmargin=0 marginheight="0" marginwidth="0" background="">
<div align=center><center>
<table width=550 border=1 cellspacing="0"><tr><td>
<table width=550 border=0><tr><td align=left><img src="http://www.exist.ru/image
/infologo.gif"></td>
<th>рПЮМЯОНПРМЮЪ МЮЙКЮДМЮЪ ╧ SN026987T
</font></b></th></tr></table>
<table width=550 border=0>
<tr><td><b><font size=1>лНЯЙБЮ, СК. бЕПУМЪЪ яШПНЛЪРМХВЕЯЙЮЪ, ДНЛ 2, РЕК.: 917-99
-40</font></b></td><th><font size=1>дЮРЮ: 08.04.02 12:01:00</font>
</th></tr>
</table>
</th></tr>
</table>
<table width="550" border=0 bgcolor="#ffffcc"><tr>
<td>
<p>оНКСВЮРЕКЭ :оЕПЖЕБ йХПХКК
<br>оНЕГД ╧ :
<br>аНПР. МНЛЕП :
<br>мНЛЕП БЮЦНМЮ :
<br>хЛЪ ОПНБНДМХЙЮ :
<br>йНКХВЕЯРБН ЛЕЯР : 1
<br><b>нРОПЮБКЪК : хКЭХМШУ йНМЯРЮМРХМ</b>
<br><b>йНЛЛЕМРЮПХИ : </b>
</td></tr>
<tr><td><table width="550" border=1 cellpadding="0" cellspacing="0">
<tr><th>╧ гЮЙЮГЮ</th><th>нОХЯЮМХЕ</th><th>тХПЛЮ</th><th>ЙНК-БН</th><th>ЖЕМЮ</th>
<th>ЯСЛЛЮ</th></tr><tr><td>IN 001406</td><td>йНЛОКЕЙР ЛНМРЮФМШИ</td><td>Ate</td>
<td>1</td><td>19.19</td><td>19.19</td></tr><tr><td>INi116167</td><td>тХКЭРП</td>
<td>Mann</td><td>1</td><td>9.27</td><td>9.27</td></tr>
</table>
<table width="550" border=0><tr>
<td width="270"> </td>
<th width="50">хРНЦН</th>
<th width="40">2</th>
<td width="40"> </td>
<th width="50">28.46</th></tr>
</table>
</td></tr>
</table>
<p><font size=2>
юДПЕЯ НРДЕКЮ НРОПЮБНЙ: <a href=mailto:r5@exist.ru>r5@exist.ru</a></font>
<p align="center"><font size=2><a href=http://WWW.EXIST.RU>WWW.EXIST.RU</a> ╘ 20
00 A+A
EXIST-INFO E-mail: <a href=mailto:info@exist.ru>info@exist.ru</a>,&nb
sp; РЕК.: (095) 917-9940, (095) 917-9680</font>
</body>
</html>
Reporter | ||
Comment 1•23 years ago
|
||
The actual file causing a hang
Reporter | ||
Updated•23 years ago
|
Summary: browser hands when load this HTML file. 0% CPU → browser hangs when load this HTML file. 0% CPU
Comment 2•23 years ago
|
||
wfm, windows nt, build 2002040803
Doesn't hang on linux 2002040510. Could you try a new nightly from
http://ftp.mozilla.org/pub/mozilla/nightly/latest/ ?
That would be great. Thank's for testing mozilla.
Reporter | ||
Comment 4•23 years ago
|
||
This is a screenshot of the hang window displaying previously opened page.
The title bar of the window displays the new title, though (from exist.html),
so the parsing at least starts.
This occurence is on the nightly build (from RH7x RPMs) 2002040814 (filenames
contain 2002040811_trunk, though).
Previous installation was removed by rpm -e plus rm -rf /usr/lib/mozilla
rpm -qa | grep mozilla
mozilla-mail-2002040811_trunk-0_rh7
mozilla-nspr-2002040811_trunk-0_rh7
mozilla-2002040811_trunk-0_rh7
mozilla-psm-2002040811_trunk-0_rh7
mozilla-nss-2002040811_trunk-0_rh7
cat /etc/redhat-release
Red Hat Linux release 7.1 (Seawolf)
uname -a
Linux kika.netli.ru 2.4.12 #5 Чтв Янв 3
19:48:41 MSK 2002 i686 unknown
ldd mozilla-bin
/lib/libsafe.so.1.3 => /lib/libsafe.so.1.3 (0x40018000)
libgkgfx.so => /usr/lib/libgkgfx.so (0x4002d000)
libjsj.so => /usr/lib/libjsj.so (0x40055000)
libmozjs.so => /usr/lib/libmozjs.so (0x4006e000)
libxpcom.so => /usr/lib/libxpcom.so (0x400de000)
libplds4.so => /usr/lib/libplds4.so (0x401d5000)
libplc4.so => /usr/lib/libplc4.so (0x401d8000)
libnspr4.so => /usr/lib/libnspr4.so (0x401dd000)
libpthread.so.0 => /lib/i686/libpthread.so.0 (0x4020b000)
libdl.so.2 => /lib/libdl.so.2 (0x40220000)
libgtk-1.2.so.0 => /usr/lib/libgtk-1.2.so.0 (0x40224000)
libgdk-1.2.so.0 => /usr/lib/libgdk-1.2.so.0 (0x40359000)
libgmodule-1.2.so.0 => /usr/lib/libgmodule-1.2.so.0 (0x4038f000)
libglib-1.2.so.0 => /usr/lib/libglib-1.2.so.0 (0x40392000)
libXi.so.6 => /usr/X11R6/lib/libXi.so.6 (0x403b7000)
libXext.so.6 => /usr/X11R6/lib/libXext.so.6 (0x403bf000)
libX11.so.6 => /usr/X11R6/lib/libX11.so.6 (0x403ce000)
libm.so.6 => /lib/i686/libm.so.6 (0x404ae000)
libc.so.6 => /lib/i686/libc.so.6 (0x404d2000)
libstdc++-libc6.2-2.so.3 => /usr/lib/libstdc++-libc6.2-2.so.3
(0x40602000)
/lib/ld-linux.so.2 => /lib/ld-linux.so.2 (0x40000000)
Reporter | ||
Comment 5•23 years ago
|
||
Checked at home with RH7.2 (upgraded kernel 2.417) and Mozilla 2002020415 (0.9.8)
Works flawlessly.
Additional note: at work I have Xinerama on dual headed Matrox G450. Will try to
launch X without Xinerama tomorrow and check.
Reporter | ||
Comment 6•23 years ago
|
||
Yes, it was Xinerama. When I start X without xinerama, file displays properly.
Everything else same, but startx -- +xinerama and the browser hangs. Tried
several times, 100% reproducible.
I'll attach my XF86Config-4 for convenience.
Reporter | ||
Comment 7•23 years ago
|
||
adding to summary
Summary: browser hangs when load this HTML file. 0% CPU → browser hangs when load this HTML file. 0% CPU (Xinerama)
Comment 9•22 years ago
|
||
I see this also. More info: The bug manifests ONLY when
- running +xinerama
- displaying int'l chars!!
http://www.fcusack.com/foo.good.html is a 'foo' search on google with the prefs
set to display only english results. This page renders properly.
http://www.fcusack.com/foo.bad.html is a 'foo' search on google with the prefs
set to display results in all languages. It contains japanese characters. It
hangs mozilla hard.
100% reproducible. nasty.
ISTM this is VERY UNLIKELY to be a bug in xfree86/xinerama itself.
[ This is on mozilla 1.0, "build ID: 2002052918" and also ximiam mozilla-1.0-5 ]
After I submit this info I will see if the file attached to this bug crashes my
mozilla.
Comment 10•22 years ago
|
||
The file attached to this bug report does NOT hang my mozilla. I tried viewing
directly (clicking on the link in bugzilla) and saving to disk and viewing that
file. I survived both to add this info. :-)
Comment 11•22 years ago
|
||
If I disable xfs there is no hang. (I used xset to change the font path.)
mozilla is stuck in select() when hung.
#0 0x4058b17e in __select () from /lib/libc.so.6
#1 0x404be34c in _XlcPublicMethods () from /usr/X11R6/lib/libX11.so.6
#2 0x4041259a in _XRead () from /usr/X11R6/lib/libX11.so.6
#3 0x40412ff5 in _XReply () from /usr/X11R6/lib/libX11.so.6
#4 0x403fd736 in XGetImage () from /usr/X11R6/lib/libX11.so.6
#5 0x409845b7 in nsXFontAAScaledBitmap::GetScaledGreyImage ()
from /usr/local/lib/mozilla-1.0.0/components/libgfx_gtk.so
#6 0x409841f4 in nsXFontAAScaledBitmap::DrawText8or16 ()
from /usr/local/lib/mozilla-1.0.0/components/libgfx_gtk.so
#7 0x40984084 in nsXFontAAScaledBitmap::DrawText16 ()
from /usr/local/lib/mozilla-1.0.0/components/libgfx_gtk.so
#8 0x40991091 in nsFontGTKNormal::DrawString ()
from /usr/local/lib/mozilla-1.0.0/components/libgfx_gtk.so
#9 0x4099ecbe in nsRenderingContextGTK::DrawString ()
from /usr/local/lib/mozilla-1.0.0/components/libgfx_gtk.so
#10 0x40fa7d0c in nsTextFrame::PaintUnicodeText ()
from /usr/local/lib/mozilla-1.0.0/components/libgklayout.so
#11 0x40fa60f6 in nsTextFrame::Paint ()
from /usr/local/lib/mozilla-1.0.0/components/libgklayout.so
#12 0x40f5a653 in nsContainerFrame::PaintChild ()
from /usr/local/lib/mozilla-1.0.0/components/libgklayout.so
#13 0x40f5a545 in nsContainerFrame::PaintChildren ()
from /usr/local/lib/mozilla-1.0.0/components/libgklayout.so
#14 0x40f6c106 in nsHTMLContainerFrame::Paint ()
from /usr/local/lib/mozilla-1.0.0/components/libgklayout.so
#15 0x40f5a653 in nsContainerFrame::PaintChild ()
from /usr/local/lib/mozilla-1.0.0/components/libgklayout.so
#16 0x40f531f8 in nsBlockFrame::PaintChildren ()
from /usr/local/lib/mozilla-1.0.0/components/libgklayout.so
#17 0x40f53008 in nsBlockFrame::Paint ()
from /usr/local/lib/mozilla-1.0.0/components/libgklayout.so
#18 0x40f5a653 in nsContainerFrame::PaintChild ()
from /usr/local/lib/mozilla-1.0.0/components/libgklayout.so
#19 0x40f531f8 in nsBlockFrame::PaintChildren ()
from /usr/local/lib/mozilla-1.0.0/components/libgklayout.so
#20 0x40f53008 in nsBlockFrame::Paint ()
from /usr/local/lib/mozilla-1.0.0/components/libgklayout.so
#21 0x40f5a653 in nsContainerFrame::PaintChild ()
from /usr/local/lib/mozilla-1.0.0/components/libgklayout.so
#22 0x40f531f8 in nsBlockFrame::PaintChildren ()
from /usr/local/lib/mozilla-1.0.0/components/libgklayout.so
#23 0x40f53008 in nsBlockFrame::Paint ()
from /usr/local/lib/mozilla-1.0.0/components/libgklayout.so
#24 0x40f5a653 in nsContainerFrame::PaintChild ()
from /usr/local/lib/mozilla-1.0.0/components/libgklayout.so
#25 0x40f531f8 in nsBlockFrame::PaintChildren ()
from /usr/local/lib/mozilla-1.0.0/components/libgklayout.so
#26 0x40f53008 in nsBlockFrame::Paint ()
from /usr/local/lib/mozilla-1.0.0/components/libgklayout.so
#27 0x40f5a653 in nsContainerFrame::PaintChild ()
from /usr/local/lib/mozilla-1.0.0/components/libgklayout.so
#28 0x40f5a545 in nsContainerFrame::PaintChildren ()
from /usr/local/lib/mozilla-1.0.0/components/libgklayout.so
#29 0x40f6c106 in nsHTMLContainerFrame::Paint ()
from /usr/local/lib/mozilla-1.0.0/components/libgklayout.so
#30 0x40f6d1cd in CanvasFrame::Paint ()
from /usr/local/lib/mozilla-1.0.0/components/libgklayout.so
#31 0x40f9d4aa in PresShell::Paint ()
from /usr/local/lib/mozilla-1.0.0/components/libgklayout.so
#32 0x4114ddca in nsView::Paint ()
from /usr/local/lib/mozilla-1.0.0/components/libgkview.so
#33 0x411569e7 in nsViewManager::RenderDisplayListElement ()
from /usr/local/lib/mozilla-1.0.0/components/libgkview.so
#34 0x41156852 in nsViewManager::RenderViews ()
from /usr/local/lib/mozilla-1.0.0/components/libgkview.so
#35 0x411557bd in nsViewManager::Refresh ()
from /usr/local/lib/mozilla-1.0.0/components/libgkview.so
#36 0x41157ceb in nsViewManager::DispatchEvent ()
from /usr/local/lib/mozilla-1.0.0/components/libgkview.so
#37 0x4114d8d7 in HandleEvent ()
from /usr/local/lib/mozilla-1.0.0/components/libgkview.so
#38 0x407a9a09 in nsWidget::DispatchEvent ()
from /usr/local/lib/mozilla-1.0.0/components/libwidget_gtk.so
#39 0x407a98e8 in nsWidget::DispatchWindowEvent ()
from /usr/local/lib/mozilla-1.0.0/components/libwidget_gtk.so
#40 0x407ac70e in nsWindow::DoPaint ()
from /usr/local/lib/mozilla-1.0.0/components/libwidget_gtk.so
#41 0x407ac8bd in nsWindow::Update ()
from /usr/local/lib/mozilla-1.0.0/components/libwidget_gtk.so
#42 0x407ac581 in nsWindow::UpdateIdle ()
from /usr/local/lib/mozilla-1.0.0/components/libwidget_gtk.so
#43 0x403b7948 in g_idle_dispatch (source_data=0x407ac524,
dispatch_time=0xbffff6a8, user_data=0x0) at gmain.c:1367
#44 0x403b69f6 in g_main_dispatch (dispatch_time=0xbffff6a8) at gmain.c:656
#45 0x403b6fb1 in g_main_iterate (block=1, dispatch=1) at gmain.c:877
#46 0x403b7129 in g_main_run (loop=0x80fb408) at gmain.c:935
#47 0x402c590b in gtk_main () at gtkmain.c:524
#48 0x4079cc35 in nsAppShell::Run ()
from /usr/local/lib/mozilla-1.0.0/components/libwidget_gtk.so
#49 0x40778eb7 in nsAppShellService::Run ()
from /usr/local/lib/mozilla-1.0.0/components/libnsappshell.so
#50 0x08051f74 in getCountry ()
#51 0x0805289e in main ()
#52 0x404f69cb in __libc_start_main (main=0x8052754 <main>, argc=1,
argv=0xbffff8a4, init=0x804c25c <_init>, fini=0x8054110 <_fini>,
rtld_fini=0x4000ae60 <_dl_fini>, stack_end=0xbffff89c)
at ../sysdeps/generic/libc-start.c:92
Comment 12•22 years ago
|
||
[ This is on mozilla 1.0, "build ID: 2002052918" and also ximiam mozilla-1.0-5 ]
both builds are a bit old. Could you try a build off the current 1.0 or 1.1
branch (or trunk, which has RPMs)?
http://download.mozilla.org/pub/mozilla/nightly/
(see the latest-xxxxxxx dirs at the bottom)
if xfs is running, does Mozilla loading the page cause xfs to crash? if xfs
crashes, Mozilla will hang.
==> Intl
Assignee: sgehani → shanjian
Component: XP Apps → Internationalization
QA Contact: paw → ruixu
Comment 13•22 years ago
|
||
Works for me on 08-12 branch build / linux RH7.2.
Comment 14•22 years ago
|
||
yuying: can you verify it does NOT work on moz 1.0?
Comment 15•22 years ago
|
||
andrew: xfs does not crash. I will try a later build.
Comment 16•22 years ago
|
||
http://download.mozilla.org/pub/mozilla/nightly/latest-trunk/Red_Hat_7x_RPMS/mozilla-1.1b-2002080816_trunk.src.rpm
still hangs. I had to add --enable-xinerama to the ./configure from the spec
file.
Comment 17•22 years ago
|
||
I am running the build of Mozilla 1.0 that shipped with the Redhat GNU/Linux
Limbo beta 1, running a July CVS build of XFree86 using Xinerama on an NVidia
GF2 AGP and Matrox G450 PCI.
I experience hard locks on many pages with international characters.
The attachment 78324 [details] does NOT lock up the browser, however the
http://www.fcusack.com/foo.bad.html page referenced in comment #9 DOES.
Comment 18•22 years ago
|
||
Comment 19•22 years ago
|
||
yup, attachment 95834 [details] locks mozilla for me
Comment 20•22 years ago
|
||
I just upgraded to Mandrake 8.2 and now I've been seeing this bug. I get the
same stack trace as described, mozilla is stuck in select. I use xinerama (2
screens). I assume it was the change to 4.2 that did it, although I'm not sure
exactly what version I had before. I'm very tempted to upgrade this to blocker
as this makes the browser nearly unusable since using google has a high
probability of hanging mozilla.
I get a hang on the first testcase, didn't try the others. And I've seen this
bug with various builds over the last week or two up to current CVS.
Status: UNCONFIRMED → NEW
Ever confirmed: true
Comment 21•22 years ago
|
||
I strongly concurr on the unuseable front. As an ardent Linux and Mozilla user,
and as someone who uses their dual screens so much that giving them up isn't an
option, this bug causes me GREAT pain. I have on lost hours of work on multiple
occasions with mozilla hard locking while I have multiple browser windows each
full of tabs containing everything from commerce transactions in progress to
pages of research results. PLEASE fix this!
Comment 22•22 years ago
|
||
Good time for me to note: I am having the problem with XFree86-4.1.0 on what is
otherwise essentially a RHL6.2 system.
Comment 23•22 years ago
|
||
Slightly more info:
$ ps ax | grep mozi
24145 ? S 3:59 /usr/local/lib/mozilla-1.0.0/mozilla-bin
24151 ? S 0:00 /usr/local/lib/mozilla-1.0.0/mozilla-bin
24152 ? S 0:10 /usr/local/lib/mozilla-1.0.0/mozilla-bin
24153 ? S 0:00 /usr/local/lib/mozilla-1.0.0/mozilla-bin
24155 ? S 0:00 /usr/local/lib/mozilla-1.0.0/mozilla-bin
32007 ? S 0:00 /usr/local/lib/mozilla-1.0.0/mozilla-bin
27081 pts/2 R 0:00 grep mozi
$ strace -p 24145
select(7, [6], NULL, NULL, NULL <unfinished ...>
$ sudo lsof -nP -p 24145 -a -d 6
COMMAND PID USER FD TYPE DEVICE SIZE NODE NAME
mozilla-b 24145 frank 6u unix 0xc2677200 257596 socket
I dunno how to tell who has the other side of that socket open.
"lsof -nP -U | egrep '(0xc2677200|257596)" only shows mozilla processes.
Comment 24•22 years ago
|
||
I get the same after locking viewing Attachment 95834 [details] :
$ ps -x | grep moz
4917 ? S 0:05 /usr/lib/mozilla-1.0.1/mozilla-bin
4966 pts/3 S 0:00 grep moz
$ strace -p 4917
select(7, [6], NULL, NULL, NULL <unfinished ...>
Comment 25•22 years ago
|
||
> I dunno how to tell who has the other side of that socket open.
Based on the stack, it should be X replying to the XGetImage call.
Comment 26•22 years ago
|
||
I use 2 Monitors, hanging on 2 NVidia GeForce2 MX (one PCI one AGP), both using
the nv driver. Debian unstable, XFree 4.2 prebuilds. I didn't see crashes either
with the normal Debian unstable XFree 4.1.
(What I did see were crashes and msgs on the console about gdk/xlib errors (esp
with display redirection to the notebook, which had no Xinerama), but I saw the
very same problem with other apps, e.g. xchat, so that is not a Mozilla problem.)
Comment 27•22 years ago
|
||
Further discussion with Ben indicates that he doesn't use xfs for fonts. So, it
seems to be some interaction with xfs.
Comment 28•22 years ago
|
||
Since this bug locks my Mozilla up 5 times a day, I wrote this shell script to
kill off a Mozilla process. I have it conveniently mapped to a Gnome launcher
icon. I thought others afflicted by this bug might find this useful.
Comment 29•22 years ago
|
||
*** Bug 169295 has been marked as a duplicate of this bug. ***
Comment 30•22 years ago
|
||
*** Bug 171439 has been marked as a duplicate of this bug. ***
Comment 31•22 years ago
|
||
I will make note on here, for anyone else who is suffering throught this, that
Chris Blizzard's XFT builds from bug 126919 fixed this problem for me, and I got
nice Anti-Aliased TrueType fonts out of it too :-)
Comment 32•22 years ago
|
||
Chris Hubick wrote:
> I will make note on here, for anyone else who is suffering throught this, that
> Chris Blizzard's XFT builds from bug 126919 fixed this problem for me, and I
> got nice Anti-Aliased TrueType fonts out of it too :-)
No, that patch does not fix the problem. You're using a diffrent font API when
you enable Xft which uses a completly different codepath then.
Comment 33•22 years ago
|
||
Reporter:
1. Can you check whether the problem goes away when you put the following line
in your "prefs.js" file, please ?
-- snip --
pref("font.x11.rejectfontpattern",
"fname=.*-iso10646-.*;scalable=.*;outline_scaled=.*;xdisplay=.*;xdpy=.*;ydpy=.*;xdevice=.*");
-- snip --
2. How does your fontpath look like (e.g. we need the output of % xset q | fgrep
"/" # ...) ?
Comment 34•22 years ago
|
||
Ok, I am sorry, I was using the word "fixed" liberally, I am aware of the
different code path. It may not be fixed from the developers point of view, but
using the XFT build fixes it from the users point of view, in the sense that you
can use Mozilla with Xinerama - and not lock up.
Comment 35•22 years ago
|
||
Roland,
Adding the pref does not help
(Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.0.0) Gecko/20020801)
My fontpath is just unix/:7100. Here is my /etc/X11/fs/config:
-- snip --
#
# Default font server configuration file for Red Hat Linux
#
# allow a max of 10 clients to connect to this font server
client-limit = 10
# when a font server reaches its limit, start up a new one
clone-self = on
# alternate font servers for clients to use
#alternate-servers = foo:7101,bar:7102
# where to look for fonts
#
catalogue = /usr/X11R6/lib/X11/fonts/misc:unscaled,
/usr/X11R6/lib/X11/fonts/75dpi:unscaled,
/usr/X11R6/lib/X11/fonts/misc,
/usr/X11R6/lib/X11/fonts/Type1,
/usr/X11R6/lib/X11/fonts/Speedo,
/usr/X11R6/lib/X11/fonts/cyrillic,
/usr/X11R6/lib/X11/fonts/75dpi,
/usr/share/fonts/default/Type1
# in 12 points, decipoints
default-point-size = 120
# 100 x 100 and 75 x 75
default-resolutions = 75,75,100,100
# use lazy loading on 16 bit (usually Asian) fonts
deferglyphs = 16
# how to log errors
use-syslog = on
# don't listen to TCP ports by default for security reasons
no-listen = tcp
-- snip --
Comment 36•22 years ago
|
||
Frank Cusack wrote:
> Adding the pref does not help
OK, then "iso10646-*"-fonts are not causing this issue.
Does setting the following prefs fix the issue
-- snip --
pref("font.scale.aa_bitmap.enable", false);
-- snip --
?
Comment 37•22 years ago
|
||
user_pref("font.scale.aa_bitmap.enable", false);
fixes it!
Comment 38•22 years ago
|
||
Frank Cusack wrote:
> user_pref("font.scale.aa_bitmap.enable", false);
> fixes it!
Well, I would call that a "workaround", not a "fix"...
----
Reassigning bug to bstell, he's the expert for the AASB code...
Assignee: shanjian → bstell
Summary: browser hangs when load this HTML file. 0% CPU (Xinerama) → AASB code hangs browser when load this HTML file. 0% CPU (Xinerama)
Comment 39•22 years ago
|
||
I did a fresh moz pull/build on 2002-10-13 at around 6pm on a Redhat 6.2 system.
The attachment 78342 [details] [diff] [review] promptly displays a page with Russian/Cyrillic text.
I also saved the file to disk and checked that it displays from disk.
I tried setting pref("font.scale.aa_bitmap.always", true) to force AASB and
both the attachment and file displayed promptly.
Comment 40•22 years ago
|
||
can anyone in QA try reproducing this?
Comment 41•22 years ago
|
||
I can not reproduce the hang on 10-14-08 trunk build / linux RH7.2, the result
is same as in comment #39, with loaded the attachment # 78324 [details] or loaded from
local after saved that attached file.
"font.scale.aa_bitmap.enable", true or false and "font.scale.aa_bitmap.always",
true or false only affect the text display but there is no hang.
Comment 42•22 years ago
|
||
bstell/ylong:
Do you have multihead machines(=e.g. more than one monitor) with Xinerama
extension turned "on" or singlehead(=one monitor) machines ?
Comment 43•22 years ago
|
||
Have you guys tried testing using Franks test page at:
http://www.fcusack.com/foo.bad.html
and attachment 95834 [details] ?
In comment #17 I noted that attachment 78324 [details] never locked up for me either. But
I have been able to reproduce on both the other tests, so could you guys try
those as well.
Comment 44•22 years ago
|
||
You need to be running Xinerama with multiple heads AND you need to configure
with --with-xinerama. Can you verify that you do not see the hang under these
conditions?
/fc
Comment 45•22 years ago
|
||
do you mean building with this line in configure.in:
ac_add_options --enable-xinerama
I tested a build with this option but I only have access to single monitor
systems.
Comment 46•22 years ago
|
||
s/this line in configure.in:/this line in .mozconfig:/
Comment 47•22 years ago
|
||
yes, --enable-xinerama. If you don't have multiple heads you probably will
not be able to reproduce the bug.
Comment 48•22 years ago
|
||
how are we going to fix this?
Do you build moz?
Perhaps we could have an on-line "debugging" session.
Comment 49•22 years ago
|
||
*** Bug 174793 has been marked as a duplicate of this bug. ***
Comment 50•22 years ago
|
||
I've also tested some chinese pages with Opera with the same setup, and Opera
locks up as well. Maybe it's not a specific Mozilla issue... still it would be
nice if mozilla detected this condition and didn't use the "offending" code path.
Could anyone of the other people try to test with other browsers / i18n apps ?
(I've submitted this to XFree86 bug system as well)
Comment 51•22 years ago
|
||
I've done some more testing, and with the aa_bitmap user pref disabled, I get
the same behaviour as in Opera: the page displays correctly, but when I try to
scroll it the browser freezes. So apparently not even this fix works...
BTW, I've tested mozilla 1.1, 1.2a, and phoenix 0.3.
Comment 52•22 years ago
|
||
If scrolling fails when aasb is disabled
("user_pref("font.scale.aa_bitmap.enable", false);")
then this is not related to aasb.
Aasb has a major effect on layout; eg: it allows layout to get the font sizes it
*wants* rather that the font sizes the font subsystem *finds*.
As such, it is possible that enabling/disabling it could just change the page
layout and cause an unrelated problem to be/not-be triggered.
Perhaps we should consider taking aasb out of the title of this bug.
Comment 53•22 years ago
|
||
Hi. Today I configured my X server to use fonts directly (instead of using xfs),
and it completely fixed the problem for me. So it appears it is not a Mozilla
issue, but a XFS bug instead.
Comment 54•22 years ago
|
||
I also configured my X server to use fonts directly (instead of using xfs) like
JoĂŁo and it also works for me (Phoenix 0.3 and Mozilla 1.2b). The chinese fonts
issue is a xfs problem...
Comment 55•22 years ago
|
||
If you read the bug report comments you'll see that not using xfs is already
a known workaround. That doesn't make it an xfs problem.
Comment 56•22 years ago
|
||
Yes, and if you read comment #50, other applications are affected in this setup,
not just Mozilla, and not using xfs fixes them too... Opera was one of them, I
just tested it today and it doesn't crash anymore as well.
Comment 57•22 years ago
|
||
If we're crashing without xfs itself crashing then it's still our bug even if
there's an additional bug in xfs which makes it send garbage to mozilla.
Comment 58•22 years ago
|
||
I'm also seeing this crash very often using Xinerama. Some of the links
mentioned earlier render OK for me, others don't. If I go to google and search
on "xinerama" it hangs every time. Does anyone have a good link explaining how
to tweak XFree 4 to not use XFS ?
Comment 59•22 years ago
|
||
> ------- Additional Comment #51 From Ricardo Almeida 2002-10-21 08:47 -------
> ... with the aa_bitmap user pref disabled ... when I try to scroll it the
> browser freezes
While this problem is serious it appears not to be related to AASB so I'm
changing the title from:
AASB code hangs browser when load this HTML file. 0% CPU (Xinerama)
to
using Xinerama and Xfs can hang the browser
Summary: AASB code hangs browser when load this HTML file. 0% CPU (Xinerama) → using Xinerama and Xfs can hang the browser
Comment 60•22 years ago
|
||
I do not have access to a Xinerama system. If any progress is to be made this bug
needs to be assigned to someone who does.
Comment 61•22 years ago
|
||
*** Bug 188475 has been marked as a duplicate of this bug. ***
Comment 63•22 years ago
|
||
I believe this may be a result of some strangeness having to do with
the interaction of Gecko with the Matrox drivers, though I arrive at
this conclusion through qualitative methods. I can reproduce the hang
with Galeon, Phoenix and Mozilla. I have tested this on two systems
running Xinerama, and only the one with a Matrox card misbehaves, and
then only when using Xinerama. In both cases, Mozilla/Phoenix/Galeon
are the ONLY applications that misbehave.
It's not exactly clear what triggers the hang, since some pages that
cause the hang will often render without incident later on. However,
there is some "stickiness" to the problem, since a page that causes a
hang will always cause the same hang if the browser is killed and
restarted. This is especially annoying when trying to use Galeon's
"Restore previous session" feature.
The problem occurs most often, but not exclusively, when loading pages
with non-ASCII character sets.
I'm running Debian testing/unstable with the X Strike Force
distribution of XFree86 4.2. The problem has persisted across many
release candidates.
Here are some random facts which are probably useless, but which
may help narrow down the search if correlated with other peoples'
observations.
uname -a :
Linux zento 2.4.20 #1 Wed Jan 1 16:24:18 EST 2003 i686 AMD Athlon(tm) XP 1600+
AuthenticAMD GNU/Linux
lspci :
00:00.0 Host bridge: VIA Technologies, Inc. VT8367 [KT266]
00:01.0 PCI bridge: VIA Technologies, Inc. VT8367 [KT266 AGP]
00:09.0 VGA compatible controller: Matrox Graphics, Inc. MGA 2064W [Millennium]
(rev 01)
00:0a.0 SCSI storage controller: Adaptec AHA-2940/2940W / AIC-7871
00:0e.0 Multimedia audio controller: C-Media Electronics Inc CM8738 (rev 10)
00:11.0 ISA bridge: VIA Technologies, Inc. VT8233 PCI to ISA Bridge
00:11.1 IDE interface: VIA Technologies, Inc. Bus Master IDE (rev 06)
00:12.0 Ethernet controller: VIA Technologies, Inc. VT6102 [Rhine-II] (rev 70)
01:00.0 VGA compatible controller: nVidia Corporation NV11 [GeForce2 MX] (rev b2)
package versions:
galeon : 1.2.5-0.woody.1
galeon : 1.2.7-6
mozilla : 1.0.0-0.woody.1
mozilla : 1.2.1-9
xfree86-common : 4.2.1-3
Mozilla versions tested :
Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.0.0) Gecko/20020623
Debian/1.0.0-0.woody.1
Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.2.1) Gecko/20021226 Debian/1.2.1-9
/etc/X11/XF86Config-4 :
Section "Files"
FontPath "unix/:7100" # local font server
# if the local font server has problems, we can fall back on these
FontPath "/usr/lib/X11/fonts/misc"
FontPath "/usr/lib/X11/fonts/cyrillic"
FontPath "/usr/lib/X11/fonts/100dpi/:unscaled"
FontPath "/usr/lib/X11/fonts/75dpi/:unscaled"
FontPath "/usr/lib/X11/fonts/Type1"
FontPath "/usr/lib/X11/fonts/Speedo"
FontPath "/usr/lib/X11/fonts/100dpi"
FontPath "/usr/lib/X11/fonts/75dpi"
EndSection
Section "Module"
Load "GLcore"
Load "bitmap"
Load "dbe"
Load "ddc"
Load "dri"
Load "extmod"
Load "freetype"
Load "glx"
Load "int10"
Load "record"
Load "speedo"
Load "type1"
Load "vbe"
EndSection
Section "InputDevice"
Identifier "Generic Keyboard"
Driver "keyboard"
Option "CoreKeyboard"
Option "XkbRules" "xfree86"
Option "XkbModel" "pc104"
Option "XkbLayout" "us"
Option "XkbOptions" "ctrl:nocaps"
EndSection
Section "InputDevice"
Identifier "Configured Mouse"
Driver "mouse"
Option "CorePointer"
Option "Device" "/dev/psaux"
Option "Protocol" "ImPS/2"
Option "ZAxisMapping" "4 5"
EndSection
Section "Device"
Identifier "geforce"
Driver "nvidia"
VideoRam 65536
BusID "PCI:1:0:0"
EndSection
Section "Device"
Identifier "Matrox"
Driver "mga"
VideoRam 4096
BusID "PCI:0:9:0"
EndSection
Section "Monitor"
Identifier "19-incher"
HorizSync 30-100
VertRefresh 50-160
Option "DPMS"
EndSection
Section "Monitor"
Identifier "20-incher"
HorizSync 30-100
VertRefresh 50-160
Option "DPMS"
EndSection
Section "Screen"
Identifier "Screen1"
Device "geforce"
Monitor "19-incher"
DefaultDepth 24
SubSection "Display"
Depth 24
Modes "1600x1200" "1280x1024" "1280x960" "1152x864" "1024x768"
EndSubSection
EndSection
Section "Screen"
Identifier "Screen2"
Device "Matrox"
Monitor "20-incher"
DefaultDepth 24
SubSection "Display"
Depth 24
Modes "1280x1024" "1280x960" "1152x864" "1024x768"
EndSubSection
EndSection
Section "ServerLayout"
Identifier "Default Layout"
Screen "Screen1"
Screen "Screen2" Rightof "Screen1"
InputDevice "Generic Keyboard"
InputDevice "Configured Mouse"
EndSection
Section "DRI"
Mode 0666
EndSection
Comment 64•22 years ago
|
||
That can't be quite right, since my experience with the bug was on an ATI Radeon
Mobility 7500/M7. I've been avoiding it lately using the
disable-xfs-load-fonts-directly workaround, and my other info is as described in
the duplicate bug 188475.
Comment 65•22 years ago
|
||
I still see this with RedHat 9.0, even when using --with-xft. Any other
suggestions for a workaround?
Comment 66•22 years ago
|
||
I disabled anti-aliasing and now it doesn't hang.
Comment 67•22 years ago
|
||
I see this same problem and haven't found a workaround.
pref("font.scale.aa_bitmap.enable", false) has no effect. When this happens
(almost exclusively on Google searches; Google is set to return only English
results), xfs is consuming all available CPU and memory resources. If xfs is
disabled, the same page causes the X server process to consume all available CPU
and memory resources.
Setup:
Mozilla 1.4b
RedHat 7.3
XFree86-4.2.0-8
KDE with Xinerama enabled
Dual headed Matrox G550 with drivers from Matrox' site
Comment 68•21 years ago
|
||
I'm seeing this bug:
Debian Woody+ (some testing/unstable packages)
Mozilla 1.5b build 2003082705
XFree86 4.2.1-11
xfs 4.2.1-6
xfstt 1.4-3
I'm using Xinerama with the following cards:
01:00.0 VGA compatible controller: nVidia Corporation Vanta [NV6] (rev 15)
02:0b.0 VGA compatible controller: ATI Technologies Inc 3D Rage Pro 215GP (rev 5c)
I've tried setting
"font.scale.aa_bitmap.enable" true or false
"font.scale.aa_bitmap.always" true or false
None of those seem to help. I also tried uninstalling xfs, that didn't help.
Any clear instructions for a workaround would be greatly appreciated.
Comment 69•21 years ago
|
||
This attachment http://bugzilla.mozilla.org/attachment.cgi?id=95834&action=view
also hangs MozillaFirebird-0.6.1-i686-pc-linux-gnu.tar.gz on my machine
(remaining config as before)
Comment 70•21 years ago
|
||
*** Bug 219149 has been marked as a duplicate of this bug. ***
Comment 71•21 years ago
|
||
I am having a similar problem. My cards are:
(--) PCI:*(2:1:0) nVidia Corporation NV5M64 [RIVA TNT2 Model 64/Model 64 Pro]
rev 21, Mem @ 0xfd000000/24, 0xf0000000/25, BIOS @ 0xfeaf0000/16
(--) PCI: (2:14:0) nVidia Corporation NV5M64 [RIVA TNT2 Model 64/Model 64 Pro]
rev 21, Mem @ 0x42000000/25
Disabling Xinerama or getting rid of the XFS dependency fixed my issue. If
there is *any* debugging I can do on my end, please let me know. My system is
at your disposal (well unless you want to blow it up)! :)
Comment 72•21 years ago
|
||
*** Bug 201390 has been marked as a duplicate of this bug. ***
Comment 73•21 years ago
|
||
*** Bug 218590 has been marked as a duplicate of this bug. ***
Comment 74•21 years ago
|
||
Just to add my $0.02 in here. --enable-xft did the trick.
Using RH9 with xinerama
Matrox G400 with drivers off their site
Comment 75•21 years ago
|
||
*** Bug 226488 has been marked as a duplicate of this bug. ***
Comment 76•21 years ago
|
||
*** Bug 208510 has been marked as a duplicate of this bug. ***
Comment 77•21 years ago
|
||
*** Bug 199486 has been marked as a duplicate of this bug. ***
Comment 78•21 years ago
|
||
(In reply to comment #74)
> Just to add my $0.02 in here. --enable-xft did the trick.
what do you mean by "--enable-xft did the trick"
that --enable-xft solves the problem?
Comment 79•21 years ago
|
||
Using --enable-xft fixed the problem. Mozilla will no longer freeze when
rendering unicode characters. I have been using xft for months now and have
never experienced a freeze outside of flash.
Comment 80•21 years ago
|
||
Yes, it appears that my configure script was too old. I'm now using the correct
invocation for xft and it seems to be working nicely now (including anti-aliased
fonts). :-)
That doesn't fix this bug though...
Comment 81•20 years ago
|
||
I don't know if this is related:
http://forums.mozillazine.org/viewtopic.php?t=80339
Comment 82•20 years ago
|
||
*** Bug 168789 has been marked as a duplicate of this bug. ***
Comment 83•20 years ago
|
||
Related to https://bugs.freedesktop.org/show_bug.cgi?id=3040 in the Xserver perhaps?
Comment 84•20 years ago
|
||
sounds like it. I'm pretty sure someone also filed a bug with XFree86 although
nobody ever figured out what was going on.
(this bug is INVALID -- it's only open as a dupe catcher)
Assignee: bstell → smontagu
Whiteboard: INVALID
Updated•15 years ago
|
QA Contact: amyy → i18n
Comment 85•14 years ago
|
||
marking invalid because we got no new dupes in several years
Status: NEW → RESOLVED
Closed: 14 years ago
Resolution: --- → INVALID
You need to log in
before you can comment on or make changes to this bug.
Description
•