On Wed, 21 May 2008 19:34:50 -0400 Yaroslav Halchenko wrote: > didn't reproduce the bug -- went through ok - didn't stall at any > slide... didn't crash after... > > lets first verify that your /tmp/ had sufficient amount of space ;)
$ df --si /tmp/ Filesystem Size Used Avail Use% Mounted on /dev/mapper/...-tmp 390M 11M 360M 3% /tmp > and then your RAM (and virtual memory) $ free -b total used free shared buffers cached Mem: 507858944 501751808 6107136 0 13824000 209612800 -/+ buffers/cache: 278315008 229543936 Swap: 2000674816 0 2000674816 > -- total amount of VRAM needed for > caching your presentation is around 460MB. not sure what was max size of > rendered page -- but I guess it would be great if your /tmp had at least > 100MB free? I can understand that the presentation is long and so it may be not possible to cache it entirely, depending on the available resources... But anyway, we are talking about an unhandled exception here. A robust program should be able to cope with exceptions without crashing. I think keyjnote should check (by catching relevant exceptions) whether a required resource (mass memory, central/virtual memory, ...) could be successfully acquired. In case it could not, keyjnote should refrain from caching the entire presentation and cache only a (moving) part of it... without crashing! I hope I clarified what I mean. Please forward this bug report to upstream, if appropriate. -- http://frx.netsons.org/doc/index.html#nanodocs The nano-document series is here! ..................................................... Francesco Poli . GnuPG key fpr == C979 F34B 27CE 5CD8 DC12 31B5 78F4 279B DD6D FCF4
pgpkwGox4PH9m.pgp
Description: PGP signature