Created attachment 2840 [details]
zip archive with H.264 draft standard, crashes OOo

Tracing system calls on the "soffice.bin" process reveals that OOo
has opened all file descriptors 0...255 (256 is the default limit for
the number of open file descriptors per process on solaris 8),
and is apparently running out of free filedescriptors:

% truss -p `pgrep soffice.bin`
... lots of truss output removed ...
open("/dev/zero", O_RDWR)                       = 255
mmap(0x00000000, 65536, PROT_READ|PROT_WRITE|PROT_EXEC, MAP_PRIVATE,
255, 0) = 0xD7A70000
close(255)                                      = 0
open64("/home/jk/OpenOffice.org1.0.1/user/temp/soffice.tmp/svb3b.tmp",
O_RDONLY|O_NDELAY) = 255
fcntl(255, F_SETFD, 0x00000001)                 = 0
fstat64(255, 0x08043708)                        = 0
close(255)                                      = 0
open("/home/jk/OpenOffice.org1.0.1/user/temp/soffice.tmp/svb3b.tmp/svbdn.tmp",
O_RDWR|O_CREAT|O_EXCL, 0666) = 255
close(255)                                      = 0
open64("/home/jk/OpenOffice.org1.0.1/user/temp/soffice.tmp/svb3b.tmp",
O_RDONLY|O_NDELAY) = 255
fcntl(255, F_SETFD, 0x00000001)                 = 0
fstat64(255, 0x0804342C)                        = 0
close(255)                                      = 0
xstat(2,
"/home/jk/OpenOffice.org1.0.1/user/temp/soffice.tmp/svb3b.tmp/svbdn.tmp",
0x08043468) = 0
open("/home/jk/OpenOffice.org1.0.1/user/temp/soffice.tmp/svb3b.tmp/svbdn.tmp",
O_RDWR) = 255
close(255)                                      = 0
gettimeofday(0x08043714)                        = 0
time()                                          = 1032025258
time()                                          = 1032025258
xstat(2,
"/home/jk/OpenOffice.org1.0.1/user/temp/soffice.tmp/svb3b.tmp/svbdn.tmp",
0x08043360) = 0
open("/home/jk/OpenOffice.org1.0.1/user/temp/soffice.tmp/svb3b.tmp/svbdn.tmp",
O_RDWR) = 255
lseek(255, 0, SEEK_SET)                         = 0
open("/dev/zero", O_RDWR)                       Err#24 EMFILE
    Incurred fault #6, FLTBOUNDS  %pc = 0xDF8617EA
      siginfo: SIGSEGV SEGV_MAPERR addr=0x00000000
    Received signal #11, SIGSEGV [caught]
      siginfo: SIGSEGV SEGV_MAPERR addr=0x00000000
sigprocmask(SIG_SETMASK, 0xDFB8A8F4, 0x00000000) = 0
access("/home/OpenOffice.org1.0.1/program/resource/dkt64149.res", 0) = 0
lxstat(2, "/home/OpenOffice.org1.0.1/program/resource/dkt64149.res",
0x08042838) = 0
lxstat(2, "/home/OpenOffice.org1.0.1/program/resource/dkt64149.res",
0x08043178) = 0
open("/home/OpenOffice.org1.0.1/program/resource/dkt64149.res",
O_RDONLY) Err#24 EMFILE
access("/home/OpenOffice.org1.0.1/program/resource/dkt64101.res", 0)
Err#2 ENOENT
access("/home/OpenOffice.org1.0.1/program/dkt64101.res", 0) Err#2 ENOENT
access("/home/OpenOffice.org1.0.1/program/resource/dkt64144.res", 0)
Err#2 ENOENT
access("/home/OpenOffice.org1.0.1/program/dkt64144.res", 0) Err#2 ENOENT
access("/home/OpenOffice.org1.0.1/program/resource/dkt64149.res", 0) = 0
lxstat(2, "/home/OpenOffice.org1.0.1/program/resource/dkt64149.res",
0x08042838) = 0
lxstat(2, "/home/OpenOffice.org1.0.1/program/resource/dkt64149.res",
0x08043178) = 0
open("/home/OpenOffice.org1.0.1/program/resource/dkt64149.res",
O_RDONLY) Err#24 EMFILE
... more truss output removed ...


It seems OOo's memory allocator (which uses mmaped anonymous memory
obtained from /dev/zero) is unable to get memory, because it can't
open /dev/zero => EMFILE.

Of cause there is enough free memory / swap space available [2.8GB at
this time].


Possible workaround:  Raising the file descriptor limit to 1024
in the shell that starts the "soffice" program allows the file to be
opened.

Jurgen, thanks for taking the time to post this issue.

Thank you for using and supporting OOo.


Unable to duplicate on Win NT 4.0 SP6a, OOo 1.0.1.

It took OOo over 5 minutes to load this 8MB file.

MS Word takes about 2 minutes.

*** Issue 6092 has been marked as a duplicate of this issue. ***

Note: this issue is about the crash that I get on a Solaris system,
opening the attached file.  It's not about the (long) time, OOo uses
to open the file.  So, I'm not sure at all if issue 6092 is a
duplicate of this issue (esp. since issue 6092 has no testcase
attached).

Btw. it does not supprise me that you were unable to reproduce the
problem on "windows nt".  The issue was filed against Sun/Solaris.
The issue is sensitive to the number of file handles than can be
concurrently open in one process.  The default limit for solaris is
256 files.  The default limit for a suse 7.2 linux box is 1024 files,
so you should already have difficulties to reproduce the issue on the
linux box, unless to lower the per-process file desc limit.

I don't know the details for windows nt, but I guess you're able to
open more than 256 files on a windows box, so this explains why
you're unable to reproduce the issue on windows.

Does this problem still exist with the latest version of OOo?

I've just tried to open the JVT-D157.doc file with OOo 1.0.3, on
Solaris 8 SPARC and x86.

Problem is, OOo 1.0.3 now hangs when trying to open this file.  It
consumes 100% cpu time and the soffice.bin process size is slowly
growing.  There's not much system call activity: I see brk() calls,
and occasional gettimeofday, sigprocmask, setitimer, setcontext calls
(probably some background thread).

On an AMD MP1800+ CPU, it has consumed >25 minutes user cpu
time, before I killed it.  I'm going to attach some stack backtraces
for the busy soffice.bin process.

Using pfiles, I see that OOo 1.0.3 has opened 199 filedescriptors.


I also double checked with OOo 1.0.1, it doesn't hang but crashes
(so the original issue is still reproducable on this Solaris 8 x86
system).

OOo 1.0.1 consumes 2min 17sec cpu time to open the problematic file on
the AMD MP1800+ system, when the filedescriptor limit is raised to
512 descriptors for the OOo process.

Created attachment 6959 [details]
Stack backtrace for the hanging OOo 1.0.3, trying to open JVT-D157.doc

Created attachment 6960 [details]
Another OOo 1.0.3 stack backtrace

Created attachment 6961 [details]
And a third stack backtrace for OOo 1.0.3

I'd say issue 6991 is a duplicate of this one (or vice versa).

  http://www.openoffice.org/issues/show_bug.cgi?id=6991

Reassigned.

No, this is not the same problem as 6991. Crash is a different reason
(objects, which couldn't be anchored correctly).
However, it will be fixed for OO 1.1.

Verified the fix in internal CWS sw017.

Fixed in RC4.