Bug#406698: iceape-browser hangs when opening a specific webpage
mh at glandium.org
Sat Jan 13 11:35:54 CET 2007
On Sat, Jan 13, 2007 at 10:00:48AM +0100, Mike Hommey <mh at glandium.org> wrote:
> tag 406698 confirmed
> clone 406698 -1
> clone 406698 -2
> reassign -1 libxul0d
> reassign -1 iceweasel
> On Sat, Jan 13, 2007 at 02:32:40AM +0100, Eric Van Buggenhaut <ericvb at debian.org> wrote:
> > Package: iceape-browser
> > Version: 1.0.7-2
> > Severity: normal
> > When I try to open:
> > http://www.archivodefamosas.com
> > iceape-browser hangs and I have to kill -9 it
> I can confirm this behaviour with epiphany (using libxul0d) and
> iceweasel, too, though I had to scroll before it hanged.
> They seem to freeze in the "crash recovery", and the backtrace traces
> back to the same array of code, though not exactly the same.
> libxul0d traces back to a "delete utf8_spacing;" in
> nsFontMetricsPango::DrawStringSlowly while iceweasel and iceape trace
> back to the preceding "gdk_draw_layout_line(aDrawable, aGC, aX, aY, aLine);"
> Running all these through gdb reveals various glibc warnings. I even got
> a segmentation fault with iceape...
> Anyways, I ran this through valgrind, and after a while, I got this
> interesting information that may be the cause of the problem:
which, in turn, may be due to the fact that the page contains null
characters. Replacing them with spaces makes iceape and friends stop
The problem seems then to be in nsFontMetricsPango::DrawString where
g_utf16_to_utf8 will stop at null characters, in which case the string
length passed to DrawStringSlowly is much longer than what the utf8
string passed is. And utf8_spacing is created depending on the size of
this utf8 string...
More information about the pkg-mozilla-maintainers