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
--
T o m M i t c h e l l
/dev/dull where insight begins.
