Issue 101782 - Can't open calc spreadsheet - OOo hangs
Summary: Can't open calc spreadsheet - OOo hangs
Alias: None
Product: Calc
Classification: Application
Component: open-import (show other issues)
Version: OOo 3.1 RC2
Hardware: PC Windows XP
: P3 Trivial with 5 votes (vote)
Target Milestone: ---
Assignee: AOO issues mailing list
QA Contact:
Keywords: oooqa
Depends on:
Reported: 2009-05-11 18:43 UTC by cianoz
Modified: 2013-08-07 15:13 UTC (History)
4 users (show)

See Also:
Issue Type: DEFECT
Latest Confirmation in: ---
Developer Difficulty: ---

cannot open this spreadsheet with OOo 3.1 (435.30 KB, application/vnd.oasis.opendocument.spreadsheet)
2009-05-11 18:45 UTC, cianoz
no flags Details
another file that OOo 3.1 cannot open (from nework) (715.35 KB, application/vnd.oasis.opendocument.spreadsheet)
2009-05-13 12:36 UTC, cianoz
no flags Details
Windows logs about OOo hanging opening spreadsheet (31.40 KB, application/x-compressed)
2009-05-13 12:37 UTC, cianoz
no flags Details

Note You need to log in before you can comment on or make changes to this issue.
Description cianoz 2009-05-11 18:43:46 UTC
As in title. I have a spreadsheet created with previous version of OOo Calc.
Until ver 3.0.1 we could use it regularly, but with the new 3.1 it's impossible
to open it. OOo hangs for several minutes when trying and if you wait for a long
time you only have it exits without any message.

The original spreadsheet was very bigger than the one I attach here, with over
50 sheets very different one each other, filled with images, links, objects,
etc. I spent a lot of time cutting and reducing the file to find the minimum
amount of sheets that still cause the problem, and here it is the smallest file
I could produce.

Please, give it a look.
Comment 1 cianoz 2009-05-11 18:45:13 UTC
Created attachment 62174 [details]
cannot open this spreadsheet with OOo 3.1
Comment 2 Regina Henschel 2009-05-11 19:08:33 UTC
I've tested it with OOo3.1 and DEV300m47 on WinXp. For me it does not hang, but
the forth sheet, named 'file...' is missing.
Comment 3 cianoz 2009-05-13 12:34:05 UTC
Hello Regina
I can't be sure that the problem I reported can be reproduced in all systems.
Nevertheless I'm sure this is a bug in OOo 3.1. I have a LAN with several
computers, so I took the time to test opening the file in attachment from 5
different PCs. Result is always the same, I can't open the file in any case. 

I can't give clear debugging elements about the problem, but consider that I
tested in a network environment (Windows domain) so it can be possible that in
this situation there are some elements activating the problem that can be
missing in other situations, like a standalone PC or a PC not connected to a
domain, for example.

Regarding the forth sheet, i think it's possible that the problem could be
related to this. The forth sheet is named

Some considerations:

1) The sheet contains some special characters that maybe OOo 3.1 cannot handle
(not as OOo 3.0.1 could)

2) The sheet was originally a hidden sheet, self generated by OOo 3.0.x in
reason of some external links created on other sheets

3) When I try to open the file with OOo 3.1 there is a first "loading document"
stage that is completed successfully, then the "calculating" stage that is the
one not completed. The progress bar stops loading at a certain point and the
program starts to hang.

4) I have the same problem with other files similar to the one I attached. The
"A1_Materie_prime.ods" named in title of sheet 4 is an existing file to which
the original links pointed to. (Now) I tried to open this also file with OOo 3.1
and neither this one can be opened (but I can with vers 3.0.1)

5) I attach another file having the same problem (see

Some consideration about this file:

a) the sheets with long name and special characters were hidden sheets, as I
said above for the 1st file

b) there are some links that point to 'file://dbimpr/...' 
"dbimpr" is the name of a server that has been dismissed and does not exits anymore
Nevertheless, OOo 3.0.1 can still open the file, but 3.1 can't.

c) Important: the file(s) I attached cannot be opened from their original
newtwork address but I can open them with OOo 3.1 if I copy them locally to my
PC. The original URL is a folder, "mapped" locally as "M:"

Hoping it can be useful I attach also the logs that Windows creates when I
terminate OOo process while it's hanging (the logs that Windows sends to Ms when
apps crash)
Comment 4 cianoz 2009-05-13 12:36:36 UTC
Created attachment 62233 [details]
another file that OOo 3.1 cannot open (from nework)
Comment 5 cianoz 2009-05-13 12:37:31 UTC
Created attachment 62234 [details]
Windows logs about OOo hanging opening spreadsheet
Comment 6 cianoz 2009-05-13 17:05:27 UTC
This bug is a regression. I suggest to mark it as release stopper for next release.
Comment 7 jbf.faure 2009-05-18 04:38:27 UTC
Both files open without problem on my OOo 3.1 FR on Ubuntu 8.04.

Comment 8 cianoz 2009-05-18 08:35:54 UTC
So, let me understand some things.
Did you read entirely and with a bit of care what i've written?
Did you try to reproduce the problem in an environment similar to mine?
Excuse me, but as far as I see you didn't do any of both things.

I have the problem with Windows XP and you opened documents in Ubuntu. It's the
same thing I've said.
Did you do it locally or from a network? Locally there's no problem, as i said.

I use OO in an enterprise environment and the problem I pointed out *IS* a
problem in such a contest. Maybe there can be something wrong in my network, but
I need your help to figure out something more.
Comment 9 cianoz 2009-05-18 08:37:25 UTC
Edit: "It's the same thing I've said"
I mean: "It's NOT the same thing I've said"
Comment 10 tomwb 2009-05-18 11:15:44 UTC
If I open the first example in OO 2.4.1, all four sheets are there.  It does not
show any external links (Edit | Links... is grayed out).  The first sheet links
to the fourth sheet.

When I open it in OO 3.1, calc it asks if you want to update links(to the
missing fourth sheet which it thinks is a original file), and the fourth sheet
is missing(Nothing to unhide).  If you open up the Links dialog, it is trying to
link to the external file (which is now the missing sheet).

windows vista

Comment 11 tomwb 2009-05-18 11:44:30 UTC
As a further test, using OO 2.4.1, I saved the first example as an excel file. 
This process changed the long fourth sheet name to just sheet5 and the order of
the sheets.  The first sheet became the second sheet, but it still maintained
the links to the newly named fourth sheet.  

OO 3.1 will now open this file with all four sheets.

Windows Vista

Comment 12 kpalagin 2009-06-30 12:00:21 UTC
m49 on WinXP opens both of your files just fine. Are you sure you are using OO 
built by Sun and not by go-oo project? Can you try opening your files on clean 
install of OO 3.1 on clean Windows (just OS without drivers)?
Comment 13 cianoz 2009-06-30 15:29:36 UTC
Thanks for replying, kpalagin
I made a try installing OOo 3.1.0 in a fresh Windows installation, but the
result is the same, that is, problem occurs as always.

Unfortunately this issue is not easy for me to detail although I spent a lot of
time trying to decode every detail. I guess there has to be something related to
the network and/or shared folders that is particularly relevant for this
problem. In fact, as I previously said, if I try to open the files locally
everything works.

For sure OOo 3.1.0 has a different approach to external linked spreadsheets than
previous versions, but unfortunately I've not found useful elements to give an
exact point to investigate on.

I'll try to make some more attempts to figure out some other details and I'll
report them as soon as they come.
Comment 14 noop 2009-06-30 18:56:18 UTC
Regarding your comments to JBF: It is generally helpful when others test on
alternate OS's. This helps to determine if the problem is OS specific.

I cannot reproduce on OOo 3.1.0  buildid=310m11(Build:9399). I was able to open
both files
  cannot open with OOo 3.1.ods
without issue on the following:

WinXPPro (both local and across my network)
Win2KPro (both local and across my network)

For the network tests I opened as a copy and read only; both methods work.

I also tested "This file contains links to other files. Should they be updated?"
by opening with both options: Yes and No. Selecting 'Yes' of course doesn't
updated the data for those missing links, example:
but that is expected.
Comment 15 paulwolstenholme 2009-07-02 06:16:42 UTC
This issue seems the same as the problem I am experiencing - as cianoz states it
is a difficult issue to quantify:
My calc spreadsheet has been working fine for years and links to a number of
other calc spreadsheets - all an a shared drive on a peer-peer W2k + Wxp
workgroup. I was shocked to see (after reading this issue) that it has
accumulated 37 hidden sheets over the years - possibly due to changed links.
Following the 3.0.1 -> 3.1.0 upgrade, OOo hangs when opening the file. The
status line shows "Load document" then "calculating" then "Adapt row height" but
the progress bar stops at about 30% with my only recovery option being to kill
the soffice.bin process via windows task manager.

I have found that various combinations of resaving (without any real change)
under OOo 3.0.1 or 3.0.0 combined with copying the file to another computer do
result in 3.1.0 being able to open the amended file.  In doing so I have created
one version of the file that will open or not according to which shared drive I
have saved the file on.  In both cases OOo 3.1.0 running on WinXP pro on the
same machine is trying to open the file.  In one case the file is located on a
mapped drive that happens to be a share from the same pc - and OOo hangs.  In
the other case the file is located on an unmapped share on a W2k pc - and the
spreadsheet opens.

To date I have been unable to reduce my spreadsheet to a useful example.  I also
have little knowledge of how to diagnose this further.  Presumably it has
something to do with links and hidden sheets but I'm not sure what I should
fiddle with in those areas.

It would appear that file rights or path completion on a network are a factor in
this OOo hang. I hope this assists the diagnosis process!
Comment 16 cianoz 2009-07-02 09:22:46 UTC
Thank you for you contribution paulwolstenholme.
I am sure that a (serious) problem in OOo 3.1.1 exists and it's really
frustrating for me not to be able to decode it enough to put devs in conditions
to debug it.
Comment 17 oc 2009-07-02 15:23:34 UTC
Hi Kohei, you have done some rework on external references. Any idea what could
happen here? btw: I couldn't reproduce this problem.
Comment 18 kyoshida 2009-07-02 15:53:29 UTC
@oc: well, it's hard to tell what could be happening without first reproducing
it on my end, and unfortunately while I have a good build environment set up for
windows it's not a good debug environment... slow machine, no good editor etc.  

In theory Calc shouldn't be accessing any external documents upon file open,
especially before the user answers yes to the "do you want to refresh the
external links?" dialog.  So, this hang puzzles me a bit.  Having said that,
it's entirely possible that Calc's trying to access such external document on
file open even if it's not supposed to.  If that's what's happening, then it's a
bug and it should be fixed.

To anyone who can reproduce this problem, is there any way you can sniff Calc's
network activities while opening the file?  On Linux, tools such as 'strace' can
do that, but I'm not too familiar with Windows debug tools...

@cianoz: is the external document actually present when you open the file?  If
yes, does it make any difference if you rename that file to intentionally make
it not accessible from the file being opened?
Comment 19 kyoshida 2009-07-02 16:32:29 UTC
btw, the 4th sheet missing is intentional, since the old external reference
implementation emulated external links with hidden sheet named 'file:///....'
(they are supposed to be hidden by the way, but you could easy turn it visible).
 The new implementation does not use that trick and internally stores the
external data from such sheet, hence the missing sheet.
Comment 20 kyoshida 2009-07-02 16:36:50 UTC
@cianoz: you said if you copy the file to a local drive the file opens fine. 
Can you do one thing for me?  Can you make another network drive mount to a
drive letter other than M: (say P:, it doesn't matter which letter), copy that
file to that drive and try to open it from there.  Does that work?
Comment 21 paulwolstenholme 2009-07-03 00:29:18 UTC
In my environment, the 2 examples of cianoz DO open correctly under 3.1.0.

My problematic .ods file does NOT open under 3.1.0 until I do the following:
1. Remove the drive mapping that leads to the linked files, AND
2. Move the offending file to a higher or lower folder level.
Neither action on its own will stop OOo 3.1.0 from hanging during file open.

Most oddly, after doing the above, I have found a situation where, after opening
the file, windows 'computer management' showed a file was being accessed using
file sharing that was not a linked file but rather a previous version of the
file I was opening that happened to be in the same folder.  At the time, I had
no mapped drive so it is unclear to me why the file would have been accessed via
sharing when the file I was opening was accessed via the local C: drive and not
via sharing.  I was able to repeat the situation a few times until I opened and
closed one or two other files.  Now I am unable to repeat this observation.

I'm not sure how relevant it is, but my .ods file, when opened under 3.0.1 contains:
* 18 links shown under edit - links
* 26 hidden sheets with names starting with file:///P:/ (should there be more
than 18?)
* 11 hidden sheets with names Table through to Table_11 that would appear to
contain copies of tables that once were linked but no longer are.
* 3 normal sheets that I created. (The other 37 must have been created
automatically by various release versions of OOo.)
* Note that the 40 sheets exist in a random order.
* Some file:/// sheets displayed information like:
The link could not be updated.		
File:	file:///P:/Projects/Design/PCBs/RMU/BMS-R13/bms_r13Parts.sxc	
Sheet:	PCB_Assy	
* One such file:/// sheet had column B hidden so the file name and sheet were
not visible.

I hope this information gives some clues on what I could usefully try next to
further pin the issue down.
Comment 22 paulwolstenholme 2009-07-03 00:35:06 UTC
Correction to previous posting: Please change "tables" to "sheets"

* 11 hidden sheets with names Table through to Table_11 that would appear to
contain copies of SHEETS that once were linked but no longer are.
Comment 23 paulwolstenholme 2009-07-03 03:28:13 UTC
In 3.1.0 OFFSET to a cell in another spreadsheet file always gives Err:504. The
links in my spreadsheets mostly use this feature. This means that even if I
could stop OOo from crashing when opening, my old linked spreadsheets (and I
have found many sheets that do crash) would not work on OOo 3.1.0 anyway.

The failure of OFFSET can be demonstrated by creating 2 calc files and entering
a formula into file SpreadsheetB such as:
Note that OOo will add the full path after you enter it. The function wizard
even lets you specify the link by clicking in the other spreadsheet if you have
both open.

So far I haven't been able to prove that this has anything to do with OOo
hanging.  What I do know is that after OOo does hang, memory usage increases
until something happens (such as: visual C++ runtime library - runtime error...
application requested the runtime to terminate in an unusual way).  While
hanging I've also seen the linked files on the share drive being accessed
(reported by windows 'computer management') and the file original spreadsheet
file being opened a second time (read instead of read-write access).

As I knowing nothing of OOo internals, interpretation of the symptoms and a
possible link of these issues is beyond me.
Comment 24 paulwolstenholme 2009-07-03 05:19:33 UTC
The following sequence causes OOo 3.1.0 to hang for me:
1. Using Win XP pro SP3 and OOo 3.1.0 create a new calc document and place the
following into one line on cell A2:
     "some text"; 
     'file:///P:/some path/test target.ods'#$Part_Source.$A$1:$Z$1;
The result will be #NAME? because test target.ods does not exist.
Save the new file (any name in the same folder will do)

2. Re-open the file.
OOo opens and asks if you want to update the link.  If you do nothing changes.
Save and close again.
(Maybe I didn't really need step 2.)

3. Create file P:/some path/test target.ods
Whether OOo 3.1.0 is going to hang in step 4 or not DOES depend upon the content
and OOo version of this file - in weird and wonderful ways that I do not yet

4. Repeat step 2.
This time OOo hangs before displaying the spreadsheet and before asking about
updating links.  BUT this should not happen because OOo should not have been
checking the link yet so the presence or absence of a linked file should not be
an issue.
You might not experience OOo hanging because you might have other content in
"test target.ods".  Nevertheless a suitable debugging system should be able to
prove that the file system was accessed at a time that I understand it should
not have been accessed.
Comment 25 cianoz 2009-07-06 11:11:41 UTC
Here i am. Sorry for the late reply but i have been busy and far from my usual
Thanks to everyone for the interest come out for this issue. I hope it can be fixed.

Yes, the linked file (let's call it "B") actually exists. 
If I open file "A" (the one that has links to file "B") it starts to hang before
i can reach to the window asking "This file contains links to other files.
Should they be updated?"
If i rename file "B" to intentionally make it not accessible then file "A" opens
correctly and i reach to the windows asking for links update. Whichever of two i
choose file "A" opens correctly (showing "#RIF" error where links are present
and not updated.

Regarding tracing OOo activity during opening file i'm sorry but i shouldn't
know how to do.

Trying with different drive letter and drive mount

In the working environment both files (A and B) are on
M: is a drive that mounts \\pdc\[ref_folder]

I tried this:

1) I mounted \\pdc\[ref_folder] on Z:
In this situation every file is left where it is and nothing is really moved,
only the drive letter changes.
Result: file A does not open, hangs as always and do not come to the "This file
contains links..." window

2) I mounted another network drive (Z:) on another folder (\\pdc\folder_x) and
copied here only file A.
Result: file A does not open (hangs)
Note: i didn't copy file B because links in file A point to M:\...\ so it is
useless to copy file B on a new folder unless changing links in A to make them
point to a new URL.

3) I copied both A and B on the new mounted drive (Z:) and modified manually all
links in file A making them pointing to Z:\ instead of M:\
To make this I opened the .ods file with 7zip and substituted every recurrence
of "M:/folder1/folder2/... into "Z:/" in content.xml.
I used Notepad++ for this to be sure that any formatting attribute wouldn't be
applied to the code and to preserve the UTF8 encoding.
Result: file A does not open (hangs)

I was confident that last try would have been successfully, but that didn't go
as expected.
Pratically, file A opens only if links destination files are disabled (renamed
or deleted).
Comment 26 kyoshida 2009-07-06 14:38:13 UTC
@cianoz: thanks for the additional info.  That eliminates several possible
causes I had in mind.  I assume, if both files A and B are in the local drive
(drive C), then file A opens correctly.  Is this the case?
Comment 27 paulwolstenholme 2009-07-06 22:34:48 UTC
I'm glad to see this bug can now be reproduced.
I have submitted issue 103331 regarding the problem I mentioned with OFFSET() as
it could well be unrelated.
Comment 28 kyoshida 2009-07-06 22:54:21 UTC
Well, I have not exactly reproduced it yet, as I was just trying to narrow down
my searches.  Reproducing it will be my next step.
Comment 29 thorsten.ziehm 2009-11-04 14:26:22 UTC
OOo 3.2 is in show-stopper stage. If this issue is critical for the release
please re-target this issue back. Otherwise this issue will be targeted for OOo
3.3, because of the votes.
Comment 30 paulwolstenholme 2009-11-04 20:29:27 UTC
This issue has resulted in OOo 3.0.1 and 3.1 both failing to support formulae
produced according to published techniques.  Furthermore, these formulae were
supported correctly by earlier versions.  In my opinion, software that fails in
this way will either be unable to convince users that it is a tool that can be
relied upon to get the job done, or alternatively it will lose any credibility
that it already has - and it will lose it FAST.

Fixing old features that got broken while implementing something else isn't
glamourous - and I wouldn't expect it to win popularity contests (such as
voting). Faced with a feature that doesn't work, most users would get frustrated
and switch to another product rather than fight through an issues reporting
system to have it put right (and rightly so given the lack of result I have seen
so far). Surely keeping things working reliably should automatically come above
implementing new features, regardless of voting?

I thought that my posting of Fri Jul 3 04:19:33 would have allowed someone to
realise that this bug is a symptom of linked file updates happening at the wrong
time and then being able to reproduce that.  I'm surprised that it keeps getting
put in everyone's 'too hard' basket.

Please increase the priority so OOo's reputation doesn't suffer!
Comment 31 raball 2010-07-25 20:07:44 UTC
Hi there.

Was a fix or a work around ever discovered for this problem? I'm seeing exactly
the same issue (load a .xls file that worked before after an update and it now
hangs at the "Adapt Row Height" stage of the load, file has external links but I
don't get the dialog box re updating them, the hang happens first).
Comment 32 thorsten.ziehm 2010-09-23 14:59:10 UTC
Sorry to say, but it seems that the development doesn't take care of this issue.
OOo 3.3 is in showstopper-mode. This issue is too old to be a stopper for the
current release. I change the target to OOo 3.x. Please change the target
accordingly when a fix is near to be integrated into a code line. 
Comment 33 Rob Weir 2013-07-30 02:45:35 UTC
Reset assignee on issues not touched by assignee in more than 1000 days.