[Webkit-unassigned] [Bug 165601] [GTK] WebKitWebProcess at 100% CPU loading hyphenation dictionaries (ASSERTION FAILED: xPos + prefixWidth <= availableWidth)
bugzilla-daemon at webkit.org
bugzilla-daemon at webkit.org
Mon Jan 9 06:34:30 PST 2017
https://bugs.webkit.org/show_bug.cgi?id=165601
--- Comment #8 from Michael Catanzaro <mcatanzaro at igalia.com> ---
Zan, can the problem you identified result in this assertion failure? I guess the assertion is a separate issue that just coincidentally is related to hyphenation and occurs on the same page?
(In reply to comment #5)
> With the 'en' locale, loading the Python PEP page, only three
> HyphenDictionary objects are created, with the underlying hyph_en_*.dic file
> opened and processed.
My locale is en_US.UTF-8. But I have 23 hyph_en_*.dic dictionaries installed, of which all except hyph_en_US.dic itself are symlinks to hyph_en_US.dic.
> With the 'es' locale, loading the same page, 1723 HyphenDictionary objects
> are created, loading each hyph_es_*.dic file 82 times. It still doesn't spin
> the CPU usage of the WebProcess to 100% on my system, but it's obviously a
> problem.
Thanks for debugging. :)
> While the TinyLRUCache capacity could be bumped, it should be noted that at
> least in Debian packages a lot of these locale variations for one specific
> locale under /usr/share/hyphen are simply symbolic links to that one master
> dict file. For instance, there's 21 different Spanish locales under
> /usr/share/hyphen, from Bolivian to Venezuelan, but it's 20 files just
> linking to the master hyphen_es_ES.dic file.
>
> Same for the English locales -- hyph_en_AU.dic and hyph_en_ZA.dic link to
> hyph_en_GB.dic.
>
> So we should maybe also look into detecting symlinks when storing these
> filepaths in the availableLocales() HashMap.
I guess we really ought to do both. A class named TinyLRUCache seems appropriate here, but I would never have assumed the capacity was as low as 4....
--
You are receiving this mail because:
You are the assignee for the bug.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.webkit.org/pipermail/webkit-unassigned/attachments/20170109/ba2966d8/attachment-0001.html>
More information about the webkit-unassigned
mailing list