Apache OpenOffice (AOO) Bugzilla – Full Text Issue Listing |
Summary: | Can't open calc spreadsheet - OOo hangs | ||||||||||
---|---|---|---|---|---|---|---|---|---|---|---|
Product: | Calc | Reporter: | cianoz <luczani> | ||||||||
Component: | open-import | Assignee: | AOO issues mailing list <issues> | ||||||||
Status: | CONFIRMED --- | QA Contact: | |||||||||
Severity: | Trivial | ||||||||||
Priority: | P3 | CC: | issues, jbf.faure, kpalagin, rb.henschel | ||||||||
Version: | OOo 3.1 RC2 | Keywords: | oooqa | ||||||||
Target Milestone: | --- | ||||||||||
Hardware: | PC | ||||||||||
OS: | Windows XP | ||||||||||
Issue Type: | DEFECT | Latest Confirmation in: | --- | ||||||||
Developer Difficulty: | --- | ||||||||||
Attachments: |
|
Description
cianoz
2009-05-11 18:43:46 UTC
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. |