Created attachment 62174 [details]
cannot open this spreadsheet with OOo 3.1

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.

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
"'file:///M:/listini/Lis_porte/Listino_2009/Calcolo_prezzi/A1_Materie_prime.ods'#Mat_prime"

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
"does_not_open_with_OOo_3.1_2nd_example.ods")

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)

Created attachment 62233 [details]
another file that OOo 3.1 cannot open (from nework)

Created attachment 62234 [details]
Windows logs about OOo hanging opening spreadsheet

This bug is a regression. I suggest to mark it as release stopper for next release.

Both files open without problem on my OOo 3.1 FR on Ubuntu 8.04.

Regards
JBF

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.

Edit: "It's the same thing I've said"
I mean: "It's NOT the same thing I've said"

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

TomW

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

TomW

cianoz,
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)?

Hello
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.

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
  does_not_open_with_OOo_3.1_2nd_example.ods
without issue on the following:

Linux
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:
='file:///M:/listini/Listini_Impronta/Lis_porte/Listino_2009/Calcolo_prezzi/A1_Materie_prime.ods'#$Mat_prime.H39
but that is expected.

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!

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.

Hi Kohei, you have done some rework on external references. Any idea what could
happen here? btw: I couldn't reproduce this problem.

@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?

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.

@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?

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.

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.

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:
  =OFFSET('file:SpreadsheetA.ods'#$Sheet1.C5;0;0)
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.

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:
  =MATCH(
     "some text"; 
     'file:///P:/some path/test target.ods'#$Part_Source.$A$1:$Z$1;
     0
     )
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
understand.

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.

Here i am. Sorry for the late reply but i have been busy and far from my usual
activity.
Thanks to everyone for the interest come out for this issue. I hope it can be fixed.

@kohei
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

Introduction: 
In the working environment both files (A and B) are on
M:\folder1\folder2\folder3\folder4\folder5
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).

@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?

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.

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.

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.

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!

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).

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. 

Reset assignee on issues not touched by assignee in more than 1000 days.