problems with very long alt text
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. from what I could see from valgrind and top, nothing looked amiss in dillo or X, but even after dillo can finally close (if it can), too many resources are tied up somehow and I need to restart X to have a really usable system. I changed the alt text back to using drawText(), and it didn't matter much that I could see. I tried using a width of 16K instead of the 25K or so that was the real value. This didn't seem to help either.
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. -- Cheers Jorge.-
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.
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... -- Cheers Jorge.-
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? *puzzled* [1] Before and after rebooting the machine. -- Cheers Jorge.-
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.
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?
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.)
furaisanjin wrote:
2011/8/26 corvid <corvid@lavabit.com>:
I just tried running from my older slackware-13.1 partition and there was no memory-eating!
I don't have any issue on FreeBSD 8.2. it sounds like particular linux libc or kernel issue.
Jorge: Do you use the Intel x.org driver as well? It is notoriously and chronically buggy, despite(?) being written by Intel guys, and maybe that's it.
I wrote:
furaisanjin wrote:
2011/8/26 corvid <corvid@lavabit.com>:
I just tried running from my older slackware-13.1 partition and there was no memory-eating!
I don't have any issue on FreeBSD 8.2. it sounds like particular linux libc or kernel issue.
Jorge: Do you use the Intel x.org driver as well? It is notoriously and chronically buggy, despite(?) being written by Intel guys, and maybe that's it.
Tried the vesa driver, and dillo worked happily.
On Thu, Aug 25, 2011 at 10:53:50PM +0000, corvid wrote:
furaisanjin wrote:
2011/8/26 corvid <corvid@lavabit.com>:
I just tried running from my older slackware-13.1 partition and there was no memory-eating!
I don't have any issue on FreeBSD 8.2. it sounds like particular linux libc or kernel issue.
Jorge: Do you use the Intel x.org driver as well? It is notoriously and chronically buggy, despite(?) being written by Intel guys, and maybe that's it.
Yes! This notebook has it and the kernel loads "i915". Will try "vesa"... -- Cheers Jorge.-
On Thu, Aug 25, 2011 at 09:12:17PM -0300, Jorge Arellano Cid wrote:
On Thu, Aug 25, 2011 at 10:53:50PM +0000, corvid wrote:
furaisanjin wrote:
2011/8/26 corvid <corvid@lavabit.com>:
I just tried running from my older slackware-13.1 partition and there was no memory-eating!
I don't have any issue on FreeBSD 8.2. it sounds like particular linux libc or kernel issue.
Jorge: Do you use the Intel x.org driver as well? It is notoriously and chronically buggy, despite(?) being written by Intel guys, and maybe that's it.
Yes!
This notebook has it and the kernel loads "i915". Will try "vesa"...
So far, it works on FreeBSD 8.2, also for corvid with vesa, and for me in another computer with ATI video, and in my same notebook with intel drivers but from linux-2.6.32.31 times. I can't get this Debian to go VESA. Hints welcomed. It looks like an intel driver bug as corvid suggested. -- Cheers Jorge.-
Jorge Arellano Cid (2011-08-26 09:34):
I can't get this Debian to go VESA. Hints welcomed.
Perhaps make sure that you have the 'xserver-xorg-video-vesa' package and try booting with the 'i915.modeset=0' kernel parameter? But probably it is more stubborn than that, e.g. only the i915 driver knows how to initialize enough video RAM for the native resolution. In such a case running `X -depth 8` could work, but delving any deeper is probably not worth the trouble.
It looks like an intel driver bug as corvid suggested.
No crashes here with dillo3-tip and the radeon driver. -- -- Rogut?s Sparnuotos
On Fri, Aug 26, 2011 at 04:51:53PM +0300, Rogut??s Sparnuotos wrote:
Jorge Arellano Cid (2011-08-26 09:34):
I can't get this Debian to go VESA. Hints welcomed.
Perhaps make sure that you have the 'xserver-xorg-video-vesa' package
It is there.
and try booting with the 'i915.modeset=0' kernel parameter?
It made no difference :-P
But probably it is more stubborn than that, e.g. only the i915 driver knows how to initialize enough video RAM for the native resolution.
I have a "Tiny Core" linux live CD that works without the intel driver (AFAICT). No native resolution though.
In such a case running `X -depth 8` could work, but delving any deeper is probably not worth the trouble.
This gave me an idea, and guess what, if I run with the same kernel/intel-driver that crashes but with a different resolution (1024x768) there's no crash. Now, if VESA can't do the native resolution, I don't know how to get closer to a proof of a bug in the i915 driver. -- Cheers Jorge.-
On Fri, Aug 26, 2011 at 12:47:24PM -0300, Jorge Arellano Cid wrote:
On Fri, Aug 26, 2011 at 04:51:53PM +0300, Rogut??s Sparnuotos wrote:
Jorge Arellano Cid (2011-08-26 09:34):
I can't get this Debian to go VESA. Hints welcomed.
Perhaps make sure that you have the 'xserver-xorg-video-vesa' package
It is there.
and try booting with the 'i915.modeset=0' kernel parameter?
It made no difference :-P
But probably it is more stubborn than that, e.g. only the i915 driver knows how to initialize enough video RAM for the native resolution.
I have a "Tiny Core" linux live CD that works without the intel driver (AFAICT). No native resolution though.
In such a case running `X -depth 8` could work, but delving any deeper is probably not worth the trouble.
This gave me an idea, and guess what, if I run with the same kernel/intel-driver that crashes but with a different resolution (1024x768) there's no crash.
Now, if VESA can't do the native resolution, I don't know how to get closer to a proof of a bug in the i915 driver.
Maybe with http://sourceforge.net/projects/xtrace/ you can determine the problematic X11 request. I can't reproduce the crash btw. Cheers, Johannes
On Fri, Aug 26, 2011 at 12:47:24PM -0300, Jorge Arellano Cid wrote:
On Fri, Aug 26, 2011 at 04:51:53PM +0300, Rogut??s Sparnuotos wrote:
try booting with the 'i915.modeset=0' kernel parameter?
It made no difference :-P
Actually it made a difference. I can't change the resolution without the kernel argument. Thanks. BTW, although my custom xorg.conf says: Section "Device" Identifier "Card0" Driver "vesa" BusID "PCI:0:2:0" EndSection Section "Screen" Identifier "Screen0" Device "Card0" Monitor "Monitor0" SubSection "Display" Viewport 0 0 Depth 16 Modes "800x600" "1024x768" EndSubSection EndSection ... lsmod shows i915 is loaded. -- Cheers Jorge.-
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.
Here memory keeps frozen while scrolling back and forth.
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.
Here, 733 has altTextWidht=8063 // works OK 734 has altTextWidht=8074 // crashes -- Cheers Jorge.-
participants (6)
-
corvid＠lavabit.com -
furaisanjin＠gmail.com -
jcid＠dillo.org -
Johannes.Hofmann＠gmx.de -
johannes.hofmann＠gmx.de
-
rogutes＠googlemail.com