Bug 40363 - Chart wizard hangs up if date value out of range
Summary: Chart wizard hangs up if date value out of range
Status: RESOLVED FIXED
Alias: None
Product: LibreOffice
Classification: Unclassified
Component: Chart (show other bugs)
Version:
(earliest affected)
3.4.2 release
Hardware: All All
: medium major
Assignee: Eike Rathke
URL:
Whiteboard:
Keywords: regression
Depends on:
Blocks:
 
Reported: 2011-08-24 18:11 UTC by lanasth
Modified: 2011-12-01 06:25 UTC (History)
4 users (show)

See Also:
Crash report or crash signature:


Attachments
Cell A8 has a bad date value, which causes the Chart wizard to hang up (indefinitely) Calc. (11.15 KB, application/vnd.oasis.opendocument.spreadsheet)
2011-08-24 18:11 UTC, lanasth
Details
same bugdoc with the correct offending date (13.36 KB, application/vnd.oasis.opendocument.spreadsheet)
2011-11-28 04:12 UTC, Jean-Baptiste Faure
Details

Note You need to log in before you can comment on or make changes to this bug.
Description lanasth 2011-08-24 18:11:20 UTC
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.
Comment 1 Rainer Bielefeld Retired 2011-08-24 22:05:47 UTC
[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 2 lanasth 2011-08-25 07:34:18 UTC
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).
Comment 3 Rainer Bielefeld Retired 2011-11-10 23:03:11 UTC
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>
Comment 4 Jean-Baptiste Faure 2011-11-12 04:45:50 UTC
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
Comment 5 pierre-yves samyn 2011-11-12 04:54:06 UTC
Hello

(In reply to comment #4)
> Same problem occurs in the current release (3.4.4)

Yes, reproduced with XP & W7

Regards
Comment 6 lanasth 2011-11-17 19:05:16 UTC
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.
Comment 7 Rainer Bielefeld Retired 2011-11-22 08:47:50 UTC
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?
Comment 8 Kohei Yoshida 2011-11-22 14:31:18 UTC
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.
Comment 9 Jean-Baptiste Faure 2011-11-24 02:06:58 UTC
(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. ;-)
Comment 10 Jean-Baptiste Faure 2011-11-24 02:15:09 UTC
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.
Comment 11 Jean-Baptiste Faure 2011-11-24 02:17:28 UTC
Set keyword regression because it works in LibO 3.3.2 from Ubuntu PPA for Ubuntu 10.04.
Comment 12 Jean-Baptiste Faure 2011-11-28 04:12:24 UTC
Created attachment 53899 [details]
same bugdoc with the correct offending date
Comment 14 Eike Rathke 2011-11-29 17:49:33 UTC
Bah, forgot to commit the header file, so this is also needed
http://cgit.freedesktop.org/libreoffice/core/commit/?id=2b2f6abfcc83c4701b42c92c6209a1052324f0a5
Comment 15 Jean-Baptiste Faure 2011-11-30 20:42:51 UTC
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
Comment 16 Eike Rathke 2011-12-01 05:11:49 UTC
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?
Comment 17 Kohei Yoshida 2011-12-01 06:25:12 UTC
(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.