Hello all,
This i very odd, I haven't seen this for years. I have a JPEG/JFIF that when opened with Mozilla will lock the whole system, and sometimes will reboot the system after a little while.
My short investigation led me to conclude that this is a bug both in kernel (as it reboots) and in Gecko-based browsers - gecko is the HTML rendering engine used in Mozilla, Firefox, Epiphany and probably others. This last assumption is due that Konqueror will not crash.
Unfortunely, the JPEG file has some sensitive information, and this hasn't happened with anyother. No error messages, nothing. I'm looking for ways to debug this, both firefox and the kernel. How do I do that?
This is the information for the file: snapshot.jpg: JPEG image data, JFIF standard 1.00, resolution (DPI), "LEAD Technologies Inc. V1.01", 200 x 200
Moreover, all mentioned browsers are included in the standard FC2, except for firefox (0.8-3, rpm by Dag Wieers[1]). Tested with the original FC2 kernel (2.6.5-358) and a with vanilla 2.6.7.
Despite gecko probably having a bug, what does that have to do with the kernel?
[1] http://dag.wieers.com/home-made/apt/
On Sat, Jul 24, 2004 at 04:05:45PM +0100, Nuno Tavares wrote:
This i very odd, I haven't seen this for years. I have a JPEG/JFIF that when opened with Mozilla will lock the whole system, and sometimes will reboot the system after a little while.
My short investigation led me to conclude that this is a bug both in kernel (as it reboots) and in Gecko-based browsers - gecko is the HTML rendering engine used in Mozilla, Firefox, Epiphany and probably others. This last assumption is due that Konqueror will not crash.
Unfortunely, the JPEG file has some sensitive information, and this hasn't happened with anyother. No error messages, nothing. I'm looking for ways to debug this, both firefox and the kernel. How do I do that?
Just guessing... Research compression bombs in this mailing list and in Google.
Make sure that you have limits (ulimit -a) that are within the bounds of physical DRAM then launch the browser.
If you are not root, and the kernel causes a reboot then you have a bug. Perhaps it is a bug in the hardware gfx side of the windowing system.
Are you fully up2date?
Hi Mitch,
Em Sun, 25 Jul 2004 00:41:28 -0700, Nifty Hat Mitch escreveu:
Just guessing... Research compression bombs in this mailing list and in Google.
How do you mean?
Make sure that you have limits (ulimit -a) that are within the bounds of physical DRAM then launch the browser.
$ ulimit -a core file size (blocks, -c) 0 data seg size (kbytes, -d) unlimited file size (blocks, -f) unlimited max locked memory (kbytes, -l) unlimited max memory size (kbytes, -m) unlimited open files (-n) 1024 pipe size (512 bytes, -p) 8 stack size (kbytes, -s) 10240 cpu time (seconds, -t) unlimited max user processes (-u) 6143 virtual memory (kbytes, -v) unlimited
Is this acceptable?
If you are not root,
I'm not, in any circumstance.
and the kernel causes a reboot then you have a bug. Perhaps it is a bug in the hardware gfx side of the windowing system.
You seem to be right. I'm using the NVIDIA module (latest) and if I change the xorg's config and use "nv" default module and doesn't crash.
Is it possible to debug the module?
Thanks for the help. - Nuno Tavares
On Tue, Jul 27, 2004 at 02:06:52AM +0100, Nuno Tavares wrote:
Em Sun, 25 Jul 2004 00:41:28 -0700, Nifty Hat Mitch escreveu:
Just guessing... Research compression bombs in this mailing list and in Google.
How do you mean?
Many compressed files (which include image files) can look small but expand to become vast files on disk or in memory when decompressed.
$ ls -l total 700 -rw-rw-r-- 1 mitch mitch 41000 Jul 30 15:03 hunk -rw-rw-r-- 1 mitch mitch 656000 Jul 30 15:05 junk $ gzip -v * hunk: 99.9% -- replaced with hunk.gz junk: 99.9% -- replaced with junk.gz $ ls -l total 16 -rw-rw-r-- 1 mitch mitch 80 Jul 30 15:03 hunk.gz -rw-rw-r-- 1 mitch mitch 677 Jul 30 15:05 junk.gz
When the browser attempts to render the image you have it may be trying to map all the bits into memory. Your 50K image might expand to a GB ;-)
I have found a .png image with a byte count of 44024 that expands to 1GB. and a 25527 byte gif that expands to 100MB.
You should save the file to disk and then run "identify" on it. Thus:
$ identify p* picture-1G.png[2] PNG 19000x19000+0+0 PseudoClass 1c 8-bit 43.0kb 10.220u 0:12
You can see that 19000x19000+0+0 expands to a massive array. It gets so big that nautilus exits on me while generating a thumbnail.
Make sure that you have limits (ulimit -a) that are within the bounds of physical DRAM then launch the browser.
$ ulimit -a core file size (blocks, -c) 0 data seg size (kbytes, -d) unlimited file size (blocks, -f) unlimited max locked memory (kbytes, -l) unlimited max memory size (kbytes, -m) unlimited open files (-n) 1024 pipe size (512 bytes, -p) 8 stack size (kbytes, -s) 10240 cpu time (seconds, -t) unlimited max user processes (-u) 6143 virtual memory (kbytes, -v) unlimited
Is this acceptable?
Sure this is OK. However setting a limit to be smaller will let the browser run out of resources quicker. This can make things easier to debug. If the browser runs out of resources and exits then the system might not crash or appear to crash on you.
The idea is to leave some RAM for the kernel.
If you are not root,
I'm not, in any circumstance.
and the kernel causes a reboot then you have a bug. Perhaps it is a bug in the hardware gfx side of the windowing system.
You seem to be right. I'm using the NVIDIA module (latest) and if I change the xorg's config and use "nv" default module and doesn't crash.
Is it possible to debug the module?
First report the problem to nVidia!
It is most difficult to debug a program for which you do not have the source. If you change 'one' thing then 80% you have identified the source of the problem. One thing that the nVidia driver can do is open a memory map between hardware and user space. If the mesa lib does one thing and the nVidia driver another then the card driver or library might go insane (never return).
In this case I believe that the root or your problem will be GL library collision. First I would remove the mesa libs then reinstall the nVidia package and fix any broken links the installer reports. Try "glxinfo", the output can help folks here see that all is ok.
I have observed SELinux issues with the nVidia installer so consider turning it off in /etc/system/selinux set SELINUX=permissive or disabled.
You can check SELinux (if you are having troubles it should be zero for nvidia install). Thus: $ cat /selinux/enforce 0$ Heck you can change it on the fly: $ echo -n 0 > /selinux/enforce # off $ echo -n 1 > /selinux/enforce # on
-
Nuno Tavares -
Tom Mitchell