Created attachment 75856 [details] Crash log LO 4.0.1.1 OS X 10.8.2 Steps to reproduce: * Open LO * create spreadsheet * Save as * select Microsoft Office 2003 XML (.xml) * enter name * hit save * confirm using the MS Excel 2003 format Crashlog attached
Hi, Thanks for reporting; But I can't reproduce this behavior using Mac OSX 10.8.2 (as well) with LibreOffice 4.0.0.3 and 4.0.1.2. Do you have any extensions installed? Does a user profile reset resolve this issue (guide: https://wiki.documentfoundation.org/UserProfile#Resetting_the_user_profile) Kind regards, Joren
Hey Joren, thanks for looking into this. I found two user profiles one folder "3" from LO 3. And the current "4" for LO 4.0. I deleted both and started LO to try again. But when trying to save a spreadsheet to XML again I experience a crash. Will attach another text file.
Interesting. More testing done: trying to save an empty spreadsheet to xml is working fine. Closing LO, re-open the file, enter text then save again -> crash (log attached)
Created attachment 75872 [details] crash log, after deleting user profile
More testing. 4.0.1.2 also crashes for me. log attached.
Created attachment 75874 [details] 4.0.1.2 crashing as well
Mmh, that's really odd. I still can't reproduce this behavior (same system: Mac OSX 10.8.2 and LibreOffice 4.0.1.2. I did some test using charts, numbers and text... Saving as MS Excel 2003 format doesn't result in a crash. Really odd.
SteveBell - can we get an actual document that is crashing for you so we can test with an identical document?
Reproducible with LO 4.0.1.2 under 10.7.5. Just opened up a blank spreadsheet, entered some text, saved as 2003 XML file with both English and Turkish localizations (to check whether the name Untitled 1 or Adsız 1 makes a difference), and it both crashed. It only crashes when using .XML format. I suggest we set the importance to "Blocker", once Joren and Joel could also reproduce the problem.
(In reply to comment #9) Still can't reproduce this behavior using Linux Mint 14 x64 and Mac OSX 10.8.2, both tested using 4.0.1.2. > I suggest we set the importance to "Blocker", once Joren and Joel could also > reproduce the problem. I can't, but even then "blocker" is to high. Following [1] I marked this bug as Critical Medium: * Critical: A feature result in a Crash. Even I can't confirm, we need to admit that and mark it as such. * Medium: I think affects "MANY" users is the right word, not MOST. [1] https://wiki.documentfoundation.org/images/0/06/Prioritizing_Bugs_Flowchart.jpg
Just for the record, on pc Debian x86-64 with master sources updated yesterday, I don't reproduce this. Roman/Alex: would one of you have some time to give it a try?
Oups, with mid air collision, I forgot to put you in cc when send my last comment (see https://bugs.freedesktop.org/show_bug.cgi?id=61751#c11)
joel: when the crash is happening, the xml file isn't even being created. So nothing to attach really. I'd be willing to do a screensharing session via teamviewer with one of the devs so they could have closer look. just drop me a mail.
Nah Joren has confirmed it, now need for file. Thanks though I agree with Joren's prioritization, 2003 file format is already very old and many users don't use it. Critical-Medium will get attention and is appropriate
(In reply to comment #14) > Nah Joren has confirmed it Just to be clear: I couldn't and still can't reproduce it. Thanks to Emir this bug is confirmed :-).
Maybe one of the developers can make something out of the crash log.
As I've been able to confirm this problem on an earlier release I am changing the version number as version is the earliest version that we can confirm the bug, we use comments to say that the bug exists in newer versions as well. Reproducible on LO 3.6.5.2. FYI: jorendc still can't reproduce this.
Can not reproduce with : Version 4.1.0.0.alpha0+ (Build ID: 9cae1dc5311c09168fbe1f04bea3d4ee33a04bb) on OSX 10.8.2 Tried saving an empty sheet as MS2003XL xml, no crash. Tried entering data (text, numbers, decimals) into a blank Calc file and then saving as MS2003XL xml, no crash. Alex
We need a test document, otherwise it is probably specific machine configuration dependent. Alex
Behavior is very inconsistent. As I created a test document, I was able to save a blank spreadsheet as xml. After entering information and hitting cmd + s again, I receive the usual crash. Maybe machine related but at least reproducible for me. But feel free to set to invalid. I don't care about xml format - at all. Just stumbled upon this issue by accident... Attaching my example document.
Created attachment 76155 [details] example document. blank save worked, saving with information entered not
More odd behavior: re-opening the xml file and entering info then saving did just work. - Very Strange doing that a second time, entering more info brings the crash.
I'll put Peter in CC. Excel 2003 XML filters (both import and export) use xslt based filters.
Thanks for your file. Opened, edited, saved, closed, several times, still no crash. Each time I go to save, LO asks me if I want to save it in Excel 2003 xml format or use the default Calc ODF format. Save works as expected. @Steve : do you have any accessibility tools enabled in your system preferences ? Things like dictation, or VoiceOver ? Or other tools, like Zoom, Cinch and others which rely on the Mac accessibility API ? These are known to cause instability in LO, even though some of the problems have been fixed. Alex
In LO364, crash when opening the file, gdb reports : Program received signal EXC_BAD_ACCESS, Could not access memory. Reason: KERN_PROTECTION_FAILURE at address: 0xb028afcc [Switching to process 27416 thread 0x9f0f] 0x9425f651 in xmlXPathCompOpEval () Unfortunately, my version of LO364 has no symbols, so backtrace useless. This does not occur in LibreOfficeDev (future 4.1), as I mentioned in a previous post, so it looks like it has been fixed since then. Alex
Hmm something I've noticed while playing around with this : 1) Open a blank spreadsheet 2) Type "freedom"(without the speech marks) in cell A1 3) Type =A1 in cell B1, and press enter. The text of A1 is reproduced in B1 4) Save as MSExcel2003 XML 5) Close the file. 6) Re-open the file 7) Cell B1 now contains the string of:]=[.A1] instead of freedom. Something not right there, and I suspect this is what caused LO 364 to crash. Alex
@Steve : on my system, the blank XL2003 XML file you posted opens with Tabelle1 as the name of the sheet - are you working in German or is German the default language ? Alex
Accessibility Tools: yes. I use BetterSnapTool (http://www.macupdate.com/app/mac/37265/bettersnaptool) Yes: German is my system language. I know that accessibility tools tend to mess with LO. Alex: Do you have a link to the 4.1alpha so I could test that?
Steve, you can try here : http://dev-builds.libreoffice.org/daily/master/MacOSX-Intel@3-OSX_10.6.0-gcc_4.0.1/ Bear in mind though that these are builds for testing purposes only. Alex
alex, I downloaded 4.1 alpha (from feb 24). Initial save with empty spreadsheet works. Entering info in a cell and saving again brings the crash (log attached). Again: if this is just my system, feel free to set to invalid.
Created attachment 76210 [details] Crash_Log Feb-24 4.1 alpha
Created attachment 76211 [details] test file used for 4.1alpha testing
Hey, I don't have any accessibility tools installed, except CheatSheet, and it is not even running, I use it like once or twice a month, and don't keep it running. I can still reproduce the crash. OS X 10.7.5 LO 4.0.1.2
I had a first quick look today. The issue seems to be related to the greater maximum number of rows in calc since 3.x (I don't remember since when we support more than 65536 rows). There seems to be an overflow in evaluating the number of repeated rows that leads to an endless recursion in one of the XSLT templates in table.xsl. I'll have a look later to come up with a fix. Should be easy, though. Unfortunately affects all XSLT calc export operations (for MS Excel 2003) since extending the maximum number of rows. May or may not be related to the libxslt port. The libxslt port suffers from a less graceful handling of endless recursion: depending on the maximum amount of stack available libxslt crashes or stops processing after reaching the internal treshold (which we could set considerably lower than the default, to prevent futures crashed). Whatever -- it's seriously broken. I'll try to fix it.
This is not a Mac OS issue only. I can confirm this - it is reproducible with LO 4.0.1.2 (Win7 Home, 64bit). Although, I cannot confirm it with a new empty sheet or a simple sheet with only a few numbers. I did not know about this bug report and was right now confirming the bug 55928 and there I experienced this behavior. In this bug report 55928 an ods file is attached. If I try to save this file as "Microsoft Excel 2007/2010 XML (.xlsx)" or "OpenOffice XML Spreadsheet (.xlsx)" file LO crashes. I can save it as "OpenDocument Spreadsheet (Flat XML) (.fods)", "Microsoft Excel 97/2000/XP/2003 (.xls)" and "Microsoft Excel 2003 XML (.xml)" files. But with the xml LO crashes if I try to reopen it. The fods and xls file I can reopen, but in both cases these files are much larger than the original ods file. In all cases when LO crashes I can only close it with the task manager - very critical.
Initial idea about an overflow is BS. There's some infinite recursion, but it's not directly related to the fact that we now support a larger maximum row count. The error is also present in OOo 3.4.1, there it just doesn't crash because the endless recursion happens in Java, where it just causes the export to fail, not the application to crash. Steps to reproduce: * Create new spreadsheet * Insert Test in A1 and A650 * Save as Excel 2003 XML * Close * Open saved file * Insert Text in B1 * Save. * Wait for a minute or so, then "Could not save file". LibO will crash, OOo will display an IOError. It only seems to occur when one of the rows has the repeat count set to a high value, which can be the case even in trivial files apparently. I hacked up a patch that prevents LibO from crashing and will save the file successfully, albeit not very quickly. I discovered another problem during analysis, where row offsets will not be calculated correctly on import in some cases, which I'll also provide a patch for. The problem with the "of:]=[.A1]" seems to be related to the fact that the spreadsheetml 2003 export filter only handles oooc formulas, but we now produce ODF1.2 formulas. I wonder if it's possible to export using the old notation.
The issue with formulas seems to go back to OOo 3.2.1. See this post: http://forum.openoffice.org/en/forum/viewtopic.php?f=9&t=36283&start=0
So, if you set the ODF compatibility setting to 1.0/1.1, the issue with the garbled formulas shouldn't appear in LibO 3.6.x. There's a bug in LibO 4.0 though that mangles cell references when opening (Excel 2003 XML) documents with spanned columns, which unfortunately affects all Excel 2003 XML files produced by LibO itself, because we add spanning information even to non-spanned columns.
Peter, thanks for digging into this. So should an additional separate bug be created?
WORKSFORME. NoRepro:4.2.0.2:OSX for the initial bug repro steps with an empty spreadsheet and saving that as xml. All good. Open newly saved xml file, enter text save again. All good again. This bug is getting quite confusing with 40 comments. So for any remaining issues please open a new separate bug report with clear repro steps.