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

Attachment: pgpkwGox4PH9m.pgp
Description: PGP signature

Reply via email to