Both files open in OO-1.0.1 running on Intel linux, with some font issues:

1.  some text that appears to be Helvetica/Arial Bold-Italic displays
much larger than it should, and the bold attribute is off.  Resetting
the font to Arial or Helvetia and attributes B+I and size (10pt)
results in something close to correct.

2.  as expected, many math symbols are missing

I can't reproduce the crash here.  I've tried to open english.doc and
francais.doc from the Kriging51.zip available from the above URL.  I've
tried

- OOo 1.0.1 Solaris x86
- OOo 1.0.1 Solaris SPARC
- SO 6.0 PP1 x86
- SO 6.0 PP1 SPARC

(All running on Solaris 8 with MU7 installed)

All four versions could open the two MS .DOC files just fine.  So there
probably is some other condition in your environment that triggers the
OOo crash for you. (Things like installed patches, installed custom
fonts, available free virtual memory, available temporary disk space,
...).



Since you mentioned an "out of memory" popup:  did you make sure that
your system has enough free swap space for running a huge application
like OOo?  (you may have to use "mkfile(1M)" and "swap(1M)" to 
increase swap)

The system should have plenty of swap space, it is a large system used
to run Matlab and numerical calculations.  Patches or fonts are the
likely problem. Did you observe the font problems I reported for these
docs using Linux x86? I should also note that I'm using an SGI Indigo2
for the X-server, but configured to get fonts from Sun's fs.  We won't
be installing any patches that aren't required for Matlab.   

The best approach may be to track down the font issues with the Linux
version -- understanding that might suggest a solution, or a least a
way to get more informative diagnostics on the Sun. 

> Did you observe the font problems I reported for these docs using 
> Linux x86?

The documents didn't look 100% correct,  for example there were some
"plane" icons appearing in some of the formulas.  This could be some
glyph mapping problem for one of the symbol fonts.  (I think I saw a
similar symbol font glyph mapping problem in another OOo issue.)

But it didn't crash.

> I should also note that I'm using an SGI Indigo2
> for the X-server, but configured to get fonts from Sun's fs.

Aha, this could be important.

Does your Sun system include a frame buffer, that is, is it possible
for you to re-test this document displaying to the local X11 server
on the Sun?  Does that work?

I made a few more experiments with OOo running on solaris and displaying
to remote X11 servers using the two documents, but still no crashes so
far.

Since you mention a "core dump" in the summary and the problem
description,  can you please try to extract a stack backtrace for the
crash using for example the command "pstack core" and attach it here?

Created attachment 2635 [details]
stack trace from core file

I have requested that the SUNWxwsrv package be installed so I can use
Xvfb, but meanwhile I have attached a stack trace (note that Solaris 7
ptrace doesn't do traces from core files, so I used dbx). 

I tried the Cygwin XFree86 Xserver and also got a core dump, so the
problem looks like something with our Sun configuration.

Similar problems have been reported under issue 3360 and issue 4233.

But I'm not sure if this is a duplicate, because I was able to reproduce
the crashes from 3360 and 4233 on solaris 8 sparc (including the faulty
"operator new" calls in the stack backtrace, requesting huge amounts of
memory).  But your file refuses to crash my OOo.


Your backtrace includes an "operator new[]" call, but it's just
trying to allocate a harmless amount of 0xff00 bytes (<64KByte)
(if we can believe the argument values shown in the stack backtrace).


It looks like this allocation for 64KBytes fails.  

You said your system has plenty of swap space:  I hope it's not all
in use by other applications running on that system  :-)
"swap -l"  lists enough free swap, right?


Can you please give us some details about the solaris system are you
running?  (model, cpu type, amount of memory, amount of swap, ...)

Are there any special limit settings in effect for the mathlab
or your numerical computation processes,  like a non-standard
stacksize limits?  (ulimit -a (sh) or limit (csh))



If you start openoffice,

then run " truss -t mmap,brk -p {pid-of-soffice.bin} "
in a terminal window

and then open one of the problematic word .doc files,  do you see
failed mmap or brk system calls?

Created attachment 2640 [details]
truss -t mmap,brk -p NNN for swriter opening english.doc

The system is a Ultra Enterprise 3000 with 2 processors, and is not
running any big jobs this week (end of August -- sensible people are
on holiday, and the summer students have gone).

$ uname -i
SUNW,Ultra-Enterprise

$ cat /etc/release                            
                    Solaris 7 5/99 s998s_u2SunServer_09 SPARC
           Copyright 1999 Sun Microsystems, Inc.  All Rights Reserved.
                             Assembled 19 April 1999
                     Solaris 7 Maintenance Update 4 applied
$ ulimit -a
time(seconds)        unlimited
file(blocks)         unlimited
data(kbytes)         unlimited
stack(kbytes)        8192
coredump(blocks)     unlimited
nofiles(descriptors) 64
vmemory(kbytes)      unlimited
$ swap -l
swapfile             dev  swaplo blocks   free
/dev/dsk/c0t0d0s1   32,121     16 524864  30080
/sys1/SWAP1           -       16 1023984 428928
/sys2/SWAP2           -       16 1023984 436112

I tried "ulimit -s 16000" (the maximum allowed) and
still get the core dump loading english.doc. 

You have a lot of OLE objects in your docs.
Try to tune a little bit the memory options in OOo under "Tools - 
Options - OpenOffice - Memory"

Since the similar issue 3360 has been fixed, 
the original poster should try to reproduce this bug
with ooo1.1beta.  If nothing else, he'll see that
the formulae look much better :-)

I'd be happy with resolving the bug WORKSFORME, but don't want
to step on anyone's toes...

Using OO1.1beta I reliably get the popup: "Main memory shortage. Please
quit other applications...", followed immediately by a core dump.  I 
tried changing the memory settings without success. If I set
"ulimit -s unlimited" OO1.1beta crashes without the popup.

I have opened the file with 1.0.3 and/or 1.1beta on other platforms.
There are still many problems with the fonts.

Aah, now we're getting somewhere.  I forgot that on Solaris,
the default ulimits are rather restrictive.

Can you crank up ulimit again so you don't get the dialog
box, run OpenOffice1.1beta under the debugger (dbx is ok,
but I wonder if gdb might not demangle the c++ identifiers better),
and get a stack trace of the crash?

I've updated the "version" field to reflect the fact that you've
seen the problem with 1.1 beta.

Thanks so much!

I tried to get a stack trace.  We don't have gdb on the Sun, so I used
dbx, which took 3 days to load and then dumped core:

$ ulimit -s unlimited
$ ulimit -a
time(seconds)        unlimited
file(blocks)         unlimited
data(kbytes)         unlimited
stack(kbytes)        unlimited
coredump(blocks)     unlimited
nofiles(descriptors) 64
vmemory(kbytes)      unlimited


Reading soffice.bin
Reading ld.so.1

[... days pass ...]

Reading libucppkg1.so
t@1 (l@8) signal SEGV (no mapping at the fault address) in
__align_cpy_1 at 0x7e7b06d0
0x7e7b06d0: __align_cpy_1+0x0030:       stb     %o4, [%o0 - 0x1]
(/opt/SUNWspro/bin/../WS5.0/bin/sparcv9/dbx) 
dbx: internal error: signal SIGSEGV (no mapping at the fault address)
dbx's coredump will appear in /tmp
$ ls -l /tmp/core
2337824 -rw-------   1 gwhite   bod      1196965888 May 23 08:18 /tmp/core
$ file /tmp/core 
/tmp/core:      ELF 64-bit MSB core file SPARCV9 Version 1, from 'dbx'

JA->CP: please have a look at this. Do you have an idea ?

I guess with a hard limit of 64 file descriptors you don't get far
with complex documents. 

Yes, the filedescriptor limit of 64 could be the problem.

Note the system call trace attachment for this issue:  the
file descriptor which is used to allocate anonymous memory from
swap space slowly increases and the last couple of mmaps used fd 63,
before the application crashed.


As a test I've reduced my descriptor limit to 64 and opened
english.doc. OOo 1.0.3 is using 50 out of the 64 descriptors.  It
does not yet crash, though.

When I try to open the second file francais.doc, OOo 1.0.3 crashes.

I set "ulimit -n 512" and "ulimit -s unlimited" and was able to open
the document and export to PDF.  On superficial examination the 
maths looks right!

francais.doc opens with 1.1beta and the same ulimit settings I used
to open english.doc

There is a problem with the font used for labels in the figure on the
"filresp" page, in both versions of the document.

I can't install 1.1beta2, so I opened a new issue with setup.  

both english.doc and francais.doc open with 1.0.3 on SGI, but
the figures are missing and many of the math symbols are also 
mmissing or incorrect.  On Sun, the files open in 1.0.1, with
missing figures and maths symbols.

I was able to reproduce this crash easily on Linux
by running
  ulimit -n 64
before opening the document.

This kind of smacks of a file descriptor leak.  Why
don't those file descriptors get closed?

If this bug doesn't get fixed for 1.1, the 1.1
release notes should at least have a description
of the problem and its workaround.

Reassigned to Michael.

MRU->CMC: I can also reproduce a crash on Windows with srx645m6.
For this, the MathType conversion has to be enabled.

Created attachment 6994 [details]
File from the mentioned URL.

Created attachment 7009 [details]
objects only example

When the amount of objects are over the cache size they get swapped
out, but the swapout fails because the reference count on the object
is not 1. Someone still has a handle to the object, this must be
somewhere in the change mathtype to starmath code because there is a
reference count of 1 on the object if it was not a converted one. So
SvxMSDffManager::CheckForConvertToSOObj in svx/msfilter/msdffimp.cxx
is my leading contender at the moment, will build that subproject with
debugging and explore this.

Hey, sounds like it might get fixed before 2.0!  Good luck!

Starmath objects seem always have a reference count of 2 :-(,
something of a red herring. 

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

cmc->cmc: Ancient bugtrack id #82897# "Wrong RefCount for unload" bug
seems suspiciously similiar.

Hmm, issue 16015 shows a similiar problem. With some modifications my
crash under windows goes away, but I run out of file descriptors under
solaris very quickly and still crash.

Issue 16015 is fixed now -- does that mean this issue is fixed, too?

issue 6991 may fix this for the original reporter under solaris
because the unix stacktraces and sympthoms are those of the CopyTo
leak problem.

But there is a remaining general ww8 import problem with large amounts
of objects and refcounting/unloading and the like. I have a solution
which I have just checked into a 2.0 workspace that I think will work,
but its somewhat extensive and given that this code is basically
untouched for years I'd be very unhappy with the idea of making this a
1.1 bug and throwing it in at the last minute.

reopen to reassign

cmc->mru: Working in limerickfilterteam08, may also be working in 1.1
seeing as core parts for a similiar problem were backported to that
release.

Checked fix with internal CWS filterteam08.

This will work at least with OO 2.0

Fix o.k. in OO 2.0 snapshot src680m13.