Re: problems with very long alt text

Johannes wrote:
> On Thu, Aug 25, 2011 at 08:03:05PM +0000, corvid wrote:
> > Jorge wrote:
> > > On Thu, Aug 25, 2011 at 02:36:56PM -0300, Jorge Arellano Cid wrote:
> > > > On Thu, Aug 25, 2011 at 05:15:00PM +0000, corvid wrote:
> > > > > Jorge wrote:
> > > > > > On Thu, Aug 25, 2011 at 01:53:32AM +0000, corvid wrote:
> > > > > > > 
> > > > > > > With remote stylesheets off and images off, opening
> > > > > > > http://www.dillo.org/test/long_alt_text.html
> > > > > > > and dragging the horizontal scrollbar left and right
> > > > > > > for a little while will make my machine suddenly start
> > > > > > > to page madly.
> > > > > > 
> > > > > >   Whoooooohooooo!
> > > > > > 
> > > > > >   Good catch: I got an instantaneous X server crash here.
> > > > > > 
> > > > > >   Will look into it.
> > > > > 
> > > > > With XFT disabled, this page doesn't give me any memory difficulties.
> > > > 
> > > >   *it surprises me*
> > > > 
> > > >   I've found this:
> > > > 
> > > >     * fl_width() returns OK when called by FltkPlatform::textWidth()
> > > >     * dillo-2.2.1 also crashes my X server.
> > > > 
> > > >   With this little data I tend to think there's a bug in Dillo.
> > > > Maybe a huge allocation request...
> > > 
> > >   * There's no need to disable CSS nor images here to have a
> > >     crash.
> > > 
> > >   To discard an utf8 kill-sequence, I changed the testcase into a
> > > 1106  'a'  character  repetition  (attached).  After applying the
> > > attached  debug-patch, it crashes consistently [1] with max_c=734
> > > but  not  with  max_c=733.  I  see the expected memory usage with
> > > max_c=733 .
> > > 
> > >  Is this also true in your machine?
> > 
> > With 733, I scroll back and forth, and mem used in the Mem line in
> > top goes up, up, up, while nothing out of the ordinary happens to dillo
> > or X, and the paging begins, and it takes a minute or so to notice the
> > ctrl-Q. A MSG() in drawSimpleWrappedText() says "width 5864 height 17",
> > which adds to the evidence that it may not be a 16-bit overflow.
> > 
> > 733 vs 734 makes no difference for me.
> 
> Maybe it has to do with MAXBUF in fl_draw.cxx?

I just tried running from my older slackware-13.1 partition and there
was no memory-eating!

Same dillo, same fltk, but older kernel and libs.

(It still wraps my original example onto four lines instead of looking
nice, but I believe I did see something one day in fltk's wrapping that
breaks at ~1k bytes or glyphs or something.)