Closed Bug 136362 Opened 23 years ago Closed 14 years ago

using Xinerama and Xfs can hang the browser

Categories

(Core :: Internationalization, defect)

x86
Linux
defect
Not set
normal

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 &#1093;&#1052;&#1056;&#1045;&#1055;&#1052;&#1045;&#1056;-&#1051;&#1070;&#1062;&#1070;&#1043;&#1061;&#1052; &#1070;&#1041;&#1056;&#1053;&#1043;&#1070;&#1054;&#1042;&#1070;&#1071;&#1056;&#1045;&#1048;</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>&#1088;&#1055;&#1070;&#1052;&#1071;&#1054;&#1053;&#1055;&#1056;&#1052;&#1070;&#1066;&nbsp&#1052;&#1070;&#1049;&#1050;&#1070;&#1044;&#1052;&#1070;&#1066;&nbsp&#9575;&nbspSN026987T </font></b></th></tr></table> <table width=550 border=0> <tr><td><b><font size=1>&#1083;&#1053;&#1071;&#1049;&#1041;&#1070;, &#1057;&#1050;. &#1073;&#1045;&#1055;&#1059;&#1052;&#1066;&#1066; &#1103;&#1064;&#1055;&#1053;&#1051;&#1066;&#1056;&#1052;&#1061;&#1042;&#1045;&#1071;&#1049;&#1070;&#1066;, &#1044;&#1053;&#1051; 2, &#1056;&#1045;&#1050;.: 917-99 -40</font></b></td><th><font size=1>&#1076;&#1070;&#1056;&#1070;:&nbsp;08.04.02 12:01:00</font> </th></tr> </table> </th></tr> </table> <table width="550" border=0 bgcolor="#ffffcc"><tr> <td> <p>&#1086;&#1053;&#1050;&#1057;&#1042;&#1070;&#1056;&#1045;&#1050;&#1069; :&#1086;&#1045;&#1055;&#1046;&#1045;&#1041; &#1081;&#1061;&#1055;&#1061;&#1050;&#1050; <br>&#1086;&#1053;&#1045;&#1043;&#1044; &#9575; : <br>&#1072;&#1053;&#1055;&#1056;. &#1052;&#1053;&#1051;&#1045;&#1055; : <br>&#1084;&#1053;&#1051;&#1045;&#1055; &#1041;&#1070;&#1062;&#1053;&#1052;&#1070; : <br>&#1093;&#1051;&#1066; &#1054;&#1055;&#1053;&#1041;&#1053;&#1044;&#1052;&#1061;&#1049;&#1070; : <br>&#1081;&#1053;&#1050;&#1061;&#1042;&#1045;&#1071;&#1056;&#1041;&#1053; &#1051;&#1045;&#1071;&#1056; : 1 <br><b>&#1085;&#1056;&#1054;&#1055;&#1070;&#1041;&#1050;&#1066;&#1050; : &#1093;&#1050;&#1069;&#1061;&#1052;&#1064;&#1059; &#1081;&#1053;&#1052;&#1071;&#1056;&#1070;&#1052;&#1056;&#1061;&#1052;</b> <br><b>&#1081;&#1053;&#1051;&#1051;&#1045;&#1052;&#1056;&#1070;&#1055;&#1061;&#1048; : </b> </td></tr> <tr><td><table width="550" border=1 cellpadding="0" cellspacing="0"> <tr><th>&#9575; &#1075;&#1070;&#1049;&#1070;&#1043;&#1070;</th><th>&#1085;&#1054;&#1061;&#1071;&#1070;&#1052;&#1061;&#1045;</th><th>&#1090;&#1061;&#1055;&#1051;&#1070;</th><th>&#1049;&#1053;&#1050;-&#1041;&#1053;</th><th>&#1046;&#1045;&#1052;&#1070;</th> <th>&#1071;&#1057;&#1051;&#1051;&#1070;</th></tr><tr><td>IN 001406</td><td>&#1081;&#1053;&#1051;&#1054;&#1050;&#1045;&#1049;&#1056; &#1051;&#1053;&#1052;&#1056;&#1070;&#1060;&#1052;&#1064;&#1048;</td><td>Ate</td> <td>1</td><td>19.19</td><td>19.19</td></tr><tr><td>INi116167</td><td>&#1090;&#1061;&#1050;&#1069;&#1056;&#1055;</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">&nbsp</td> <th width="50">&#1093;&#1056;&#1053;&#1062;&#1053;</th> <th width="40">2</th> <td width="40">&nbsp;</td> <th width="50">28.46</th></tr> </table> </td></tr> </table> <p><font size=2> &#1102;&#1044;&#1055;&#1045;&#1071; &#1053;&#1056;&#1044;&#1045;&#1050;&#1070; &#1053;&#1056;&#1054;&#1055;&#1070;&#1041;&#1053;&#1049;: <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> &#9560; 20 00 A+A EXIST-INFO&nbsp;&nbsp;E-mail: <a href=mailto:info@exist.ru>info@exist.ru</a>,&nb sp;&nbsp; &#1056;&#1045;&#1050;.: (095) 917-9940, (095) 917-9680</font> </body> </html>
The actual file causing a hang
Summary: browser hands when load this HTML file. 0% CPU → browser hangs when load this HTML file. 0% CPU
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.
Keywords: hang
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 &#1063;&#1090;&#1074; &#1071;&#1085;&#1074; 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)
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.
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.
adding to summary
Summary: browser hangs when load this HTML file. 0% CPU → browser hangs when load this HTML file. 0% CPU (Xinerama)
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.
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. :-)
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
[ 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
Keywords: intl
QA Contact: ruixu → ylong
Works for me on 08-12 branch build / linux RH7.2.
yuying: can you verify it does NOT work on moz 1.0?
andrew: xfs does not crash. I will try a later build.
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.
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.
yup, attachment 95834 [details] locks mozilla for me
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
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!
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.
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.
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 ...>
> 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.
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.)
Further discussion with Ben indicates that he doesn't use xfs for fonts. So, it seems to be some interaction with xfs.
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.
*** Bug 169295 has been marked as a duplicate of this bug. ***
*** Bug 171439 has been marked as a duplicate of this bug. ***
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 :-)
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.
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 "/" # ...) ?
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.
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 --
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 -- ?
user_pref("font.scale.aa_bitmap.enable", false); fixes it!
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)
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.
can anyone in QA try reproducing this?
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.
bstell/ylong: Do you have multihead machines(=e.g. more than one monitor) with Xinerama extension turned "on" or singlehead(=one monitor) machines ?
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.
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
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.
s/this line in configure.in:/this line in .mozconfig:/
yes, --enable-xinerama. If you don't have multiple heads you probably will not be able to reproduce the bug.
how are we going to fix this? Do you build moz? Perhaps we could have an on-line "debugging" session.
*** Bug 174793 has been marked as a duplicate of this bug. ***
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)
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.
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.
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.
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...
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.
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.
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.
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 ?
> ------- 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
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.
*** Bug 188475 has been marked as a duplicate of this bug. ***
change the critical to normal.
Severity: critical → normal
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
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.
Blocks: 201390
I still see this with RedHat 9.0, even when using --with-xft. Any other suggestions for a workaround?
I disabled anti-aliasing and now it doesn't hang.
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
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.
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)
Blocks: 219149
*** Bug 219149 has been marked as a duplicate of this bug. ***
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)! :)
No longer blocks: 201390
*** Bug 201390 has been marked as a duplicate of this bug. ***
No longer blocks: 219149
*** Bug 218590 has been marked as a duplicate of this bug. ***
Just to add my $0.02 in here. --enable-xft did the trick. Using RH9 with xinerama Matrox G400 with drivers off their site
*** Bug 226488 has been marked as a duplicate of this bug. ***
*** Bug 208510 has been marked as a duplicate of this bug. ***
*** Bug 199486 has been marked as a duplicate of this bug. ***
(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?
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.
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...
*** Bug 168789 has been marked as a duplicate of this bug. ***
Related to https://bugs.freedesktop.org/show_bug.cgi?id=3040 in the Xserver perhaps?
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
QA Contact: amyy → i18n
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.

Attachment

General

Creator:
Created:
Updated:
Size: