Closed
Bug 136362
Opened 22 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)
Screenshot of the browser window hanging
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•22 years ago
|
||
The actual file causing a hang
|
|
Reporter | |
Updated•22 years ago
|
Summary: browser hands when load this HTML file. 0% CPU → browser hangs when load this HTML file. 0% CPU
|
||
Comment 2•22 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•22 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•22 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•22 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•22 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•21 years ago
|
||
I still see this with RedHat 9.0, even when using --with-xft. Any other suggestions for a workaround?
|
|
||
Comment 66•21 years ago
|
||
I disabled anti-aliasing and now it doesn't hang.
|
||
Comment 67•21 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•20 years ago
|
||
*** Bug 199486 has been marked as a duplicate of this bug. ***
|
||
Comment 78•20 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•20 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•20 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•19 years ago
|
||
*** Bug 168789 has been marked as a duplicate of this bug. ***
|
||
Comment 83•19 years ago
|
||
Related to https://bugs.freedesktop.org/show_bug.cgi?id=3040 in the Xserver perhaps?
|
|
||
Comment 84•19 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
•