Created attachment 50557 [details] Cell A8 has a bad date value, which causes the Chart wizard to hang up (indefinitely) Calc. Calc will hang up if you try to start the Chart wizard with your cursor in anything other than the SE quadrant relative to your table of values, when you have a faulty date value (e.g. "05/10/811") in your list of dates (see attached spreadsheet). I'm guessing that the chart wizard is attempting to display a preview of the data that it finds surrounding, North, or East of your selected cell. Since Calc does not know how to interpret such a faulty date value, it's probably getting hung up with it's data previewer. Assuming so, it would be better for the wizard to ignore faulty values rather than trying to display them.
[Reproducible] with reporter's sample and "LibreOffice 3.4.3 RC1 - WIN7 Home Premium (64bit) German UI [OOO340m1 (Build:301)]", same problem with Master "LibO-dev 3.4.5 – WIN7 Home Premium (64bit) English UI [(Build ID:d337f79-a24c961-2865670-9752b71-7f8fd43 2fdd60d-fd28b6a-fd7bf20-aa369cb-28da3fb 6a9633a-931d089-ecd263f-c9b55e9-b31b807 82ff335-599f7e9-bc6a545-1926fdf)]" @Kohei: Please feel free to reassign (or reset Assignee to default) if it’s not your area or if provided information is not sufficient. Please set Status to ASSIGNED if you accept this Bug.
Comment on attachment 50557 [details] Cell A8 has a bad date value, which causes the Chart wizard to hang up (indefinitely) Calc. Slight correction, the hanging problem occurs when you start the chart wizard from a selected cell either in or touching the border of the data table. Starting the chart wizard in a cell that is not touching the data selection works just fine (in any direction).
Crash longer with Server installation of Master "LibO-dev 3.5.0 – WIN7 Home Premium (64bit) English UI [(Build ID: 5d1a991-4cb1bac-ca7e6f5-9125509-ce71330)]" (111109). So WFM @reporter: Please feel free to reopen this bug if you find out that the problem still exists with a more current LibreOffice 3.5 version than the one I tested. <http://wiki.documentfoundation.org/BugReport_Details#Version>
I have a more recent build of the master on Ubuntu 10.04 x86_64: LibreOffice 3.5.0 Build ID: 768567e-0bc4ff4-ca7e6f5-9125509-ce71330 and I encounter the same bug. Caution: if I open the bugdoc, the master read the erroneous date as 1899-12-30. If I change these date for 811-05-10, I reproduce the bug. Same problem occurs in the current release (3.4.4) and I think this bug should be fixed in the 3.4 branch (in 3.4.5), not only in the master. If you replace the year 811 by 4011 it works well. So the problem is not in the size of the date range. If you replace the year 811 by 1911, 1811, 1711, 1611 it works well but not with years before 1580. I don't think the problem is linked to the switch from julian calendar to gregorian calendar in the year 1582 (the day after 1582-10-04 was 1582-10-15). Indeed you can do a chart with dates before and after the critical date. Best regards. JBF
Hello (In reply to comment #4) > Same problem occurs in the current release (3.4.4) Yes, reproduced with XP & W7 Regards
I don't know why the latest 3.5 reinterpreted my bad date differently, but I can confirm that the year 855 still locks up Calc when you foolishly ask it to chart the data. Ideally it should ignore bad data like a blank cell. I'm running it on a Win7 home premium 64-bit Q6600 box.
CRASH after modification of A8 to [Reproducible] with Server installation of Master "LibO-dev 3.5.0 – WIN7 Home Premium (64bit) ENGLISH UI [(Build ID: 4f11d0a-adcf6d5-c4bb9bd)]" Windows_2008R2 - 111118) I removed target because bug currently is unaccepted. @Jean-Baptiste Faure: Brilliant! Any idea concerning the different date interpretation between LibO 3.4 and 3.5?
Before investigating this, We seem unable to save any dates prior to 999-12-27 to ods. If you enter 999-12-26, save it to ods and reload it, the date becomes 1899-12-30. Possibly related? I don't know at this point.
(In reply to comment #8) > Before investigating this, We seem unable to save any dates prior to 999-12-27 > to ods. If you enter 999-12-26, save it to ods and reload it, the date becomes > 1899-12-30. Possibly related? I don't know at this point. The problem is still there if you replace the offending date bay 1011-05-08 and save to a new ods file. So I think there is at least 2 bugs. ;-)
Did some investigations. I found that Calc call DaysToDate() function for each day until 0001-1-1 when you start the Chart2 wizard with this file modified in the way mentioned in my previous comment (year 1011 instead of 811). When it has reached 1-1-1 it continues to consume 100% CPU. I am investigating what it does at this time.
Set keyword regression because it works in LibO 3.3.2 from Ubuntu PPA for Ubuntu 10.04.
Created attachment 53899 [details] same bugdoc with the correct offending date
Freeze fixed on master with http://cgit.freedesktop.org/libreoffice/core/commit/?id=dca69d5bb2d0e542de26624dd9f71fb87e1533f2 http://cgit.freedesktop.org/libreoffice/binfilter/commit/?id=1f9150ab1bbb121c59014fba7c7cd229aceeeb66 http://cgit.freedesktop.org/libreoffice/core/commit/?id=6619955e72c1c2f29a32e82478d19147c0d7610a http://cgit.freedesktop.org/libreoffice/core/commit/?id=07a7b2937a9427b2feb3307804ec0f527091bb92 The ISO 8601 stuff is fixed with http://cgit.freedesktop.org/libreoffice/core/commit/?id=7613359985a89a42417a746bcdbb25f072784733
Bah, forgot to commit the header file, so this is also needed http://cgit.freedesktop.org/libreoffice/core/commit/?id=2b2f6abfcc83c4701b42c92c6209a1052324f0a5
Hi Eike, Awesome! Thank you very much for this clean fix. It is probably not a good idea to backport this fix to LibO 3.4. Can you confirm that ? Best regards. JBF
I would not backport the whole bunch, after all the IsValidAndGregorian() and IsValidDate() versus IsValid() went in to prevent incorrect assumptions in the future. However, I think we could add the Normalize() and ODF stuff, but so far I see this whole year<1582 thing as a rare corner case not worth the trouble. Kohei, what do you think?
(In reply to comment #16) > Kohei, what do you think? Yeah, the change is a bit too big to backport. So, I'm also in favor of not backporting this piece.