infinite loop calling FcConfigUptoDate in directory with symlinks
| Affects | Status | Importance | Assigned to | Milestone | |
|---|---|---|---|---|---|
| xulrunner-1.9 (Ubuntu) |
Invalid
|
Undecided
|
Unassigned | ||
Bug Description
Binary package hint: xulrunner-1.9
Description: Ubuntu 8.10
Release: 8.10
firefox-3.0:
Installed: 3.0.8+nobinonly
Candidate: 3.0.8+nobinonly
Version table:
*** 3.0.8+nobinonly
500 http://
500 http://
100 /var/lib/
3.
500 http://
xulrunner-1.9:
Installed: 1.9.0.8+
Candidate: 1.9.0.8+
Version table:
*** 1.9.0.8+
500 http://
500 http://
100 /var/lib/
1.
500 http://
libfontconfig1:
Installed: 2.6.0-1ubuntu4
Candidate: 2.6.0-1ubuntu4
Version table:
*** 2.6.0-1ubuntu4 0
500 http://
100 /var/lib/
I had a flash video open in one tab.
In a different tab, I clicked at an anchor link (wikipedia, so no flash involved here).
As soon as I clicked the anchor, firefox hung. 10 seconds later it responded for a fraction of a second then failed to respond after that.
My flash player version is 10,0,22,87 (the native 64-bit beta version, updated from an older 64-bit version within the past month)
I have never had this crash before--it seems to be very rare, but it is caused by a function called from Flash
strace -p PID showed firefox looking at several directories undeer /usr/share/
(it had already been hung for a minute by the time I tried this)
Upon removing the recursive "X11 -> ." symbolic link inside of /usr/share/
I am not sure what code inside xulrunner is responsible for a recursive fontconfig search, but if there is any function that recursively calls FcConfigUptoDate, it should check whether a file is a symbolic link, and if so, expand the absolute path of the symbolic link so that it can check if it is looking recursively.
Here is the GDB backtrace while it was looking through these directories -- I do not have debugging symbols because this has never happened before, but I can't imagine many duplicated places where you do recursive directory searches so it hopefully won't be too hard to find this spot):
#0 0x00007f6c916be025 in __xstat64 () from /lib/libc.so.6
#1 0x00007f6c8db34e05 in ?? () from /usr/lib/
#2 0x00007f6c8db34f04 in FcConfigUptoDate () from /usr/lib/
#3 0x00007f6c9056ebcc in ?? () from /usr/lib/
#4 0x00007f6c9056eca7 in ?? () from /usr/lib/
#5 0x00007f6c901f3c2d in ?? () from /usr/lib/
#6 0x00007f6c905512a5 in ?? () from /usr/lib/
#7 0x00007f6c901f0254 in ?? () from /usr/lib/
#8 0x00007f6c901f07db in ?? () from /usr/lib/
#9 0x00007f6c901fa05f in ?? () from /usr/lib/
#10 0x00007f6c901fa656 in ?? () from /usr/lib/
...
#103 0x00007f6c8ff2a252 in ?? () from /usr/lib/
#104 0x00007f6c8ff2aed6 in ?? () from /usr/lib/
#105 0x00007f6c8ff2b351 in ?? () from /usr/lib/
#106 0x00007f6c8ff2bf17 in ?? () from /usr/lib/
#107 0x00007f6c8ff32d67 in ?? () from /usr/lib/
#108 0x00007f6c8ff49249 in ?? () from /usr/lib/
#109 0x00007f6c8ff32d67 in ?? () from /usr/lib/
#110 0x00007f6c8ff46905 in ?? () from /usr/lib/
#111 0x00007f6c8ff46e72 in ?? () from /usr/lib/
#112 0x00007f6c8ff471bc in ?? () from /usr/lib/
#113 0x00007f6c8ff32d67 in ?? () from /usr/lib/
#114 0x00007f6c8ff78e92 in ?? () from /usr/lib/
#115 0x00007f6c8ff1559d in ?? () from /usr/lib/
---Type <return> to continue, or q <return> to quit---
#116 0x00007f6c8ff18a8f in ?? () from /usr/lib/
#117 0x00007f6c8ff18bc6 in ?? () from /usr/lib/
#118 0x00007f6c8ff18c5a in ?? () from /usr/lib/
#119 0x00007f6c90533036 in ?? () from /usr/lib/
#120 0x00007f6c9050838a in ?? () from /usr/lib/
#121 0x00007f6c9048ca84 in ?? () from /usr/lib/
#122 0x00007f6c90479074 in ?? () from /usr/lib/
#123 0x00007f6c8d454d5b in g_main_
#124 0x00007f6c8d45852d in ?? () from /usr/lib/
#125 0x00007f6c8d4586eb in g_main_
#126 0x00007f6c8c839651 in gtk_main_iteration () from /usr/lib/
#127 0x00007f6c785babab in ?? () from /usr/lib/
#128 0x00007f6c8d45551b in ?? () from /usr/lib/
#129 0x00007f6c8d454d5b in g_main_
#130 0x00007f6c8d45852d in ?? () from /usr/lib/
#131 0x00007f6c8d4586eb in g_main_
#132 0x00007f6c9048c7b1 in ?? () from /usr/lib/
#133 0x00007f6c9048c962 in ?? () from /usr/lib/
#134 0x00007f6c90532fe1 in ?? () from /usr/lib/
#135 0x00007f6c905082f6 in ?? () from /usr/lib/
#136 0x00007f6c9048ca1d in ?? () from /usr/lib/
#137 0x00007f6c9032c721 in ?? () from /usr/lib/
#138 0x00007f6c8fdb2082 in XRE_main () from /usr/lib/
#139 0x00000000004016b4 in ?? ()
#140 0x00007f6c91604466 in __libc_start_main () from /lib/libc.so.6
The strace from firefox sadly scrolled off the top of the console because I forgot to use a different terminal window, but subsequent to removing the symbolic link, it was still looking at deep directories until it finally had gone through all directories in the heirarchy and returned:
...
stat("/
stat("/
stat("/
stat("/
...
I will add the symbolic link back in, and then keep checking if I see the bug happen another time.
| Patrick Horn (phrh) wrote | #1 |
| Stephen (sdupre) wrote | #2 |
| Phillip Susi (psusi) wrote | #3 |
| Changed in xulrunner-1.9 (Ubuntu): | |
| status: | New → Invalid |
Please disregard everything to do with flash--that was probably just a coincidence because of how the main event loop runs.
I just realized that I was looking at a lot of google results for something, and in addition to the wikipedia page, I had opened this site in another tab:
http://
This page has MathML, which would very likely require looking for fonts on my hard drive, so this may indeed have been the cause of the crash.
Indeed, adding the symbolic link back and refreshing that page triggers the bug once more.
here is a page on that same site with a much more pronounced effect (probably happens once per equation): http://
Also, this is not an infinite loop, but rather a *very* *long* finite loop--it does seem to return eventually after several minutes (maybe the OS maxes out the number of recursive symbolic links you can have in a directory)
So yes the bug is entirely reproducable on sites using MathML! I probably won't have time this week to install the debug libraries for xulrunner, but I have been considering trying out the Jaunty beta. Would that help?