Bug#406698: iceape-browser hangs when opening a specific webpage

[Mike Hommey]

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
> thanks
> 
> 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);"
> line.
> 
> 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
freezing.

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...

Mike