GNOME Bugzilla – Bug 329356
crash on looping "Invaild date value" warning
Last modified: 2013-09-13 01:00:46 UTC
Please describe the problem: Because of Invaild date value in LANG=ko_KR.UTF-8, appointment Can't be saved. Ignoring Invaild date value message, and tring to save at every moment, evolution crashs. But appointment works well in en_US.UTF-8 Backtrace was generated from '/usr/bin/evolution' Using host libthread_db library "/lib/libthread_db.so.1". `shared object read from target memory' has disappeared; keeping its symbols. [Thread debugging using libthread_db enabled] [New Thread -1208441168 (LWP 4241)] [New Thread 1953926048 (LWP 4380)] [New Thread -1260520544 (LWP 4248)] [New Thread -1222100064 (LWP 4247)] 0x00ff6402 in __kernel_vsyscall ()
+ Trace 65788
Thread 1 (Thread -1208441168 (LWP 4241))
Steps to reproduce: 1. $LANG=ko_KR.UTF-8 evolution -c calendar 2. ctrl + n ( for new appointment) 3. type some string. 4. ctrl + s Actual results: Expected results: Does this happen every time? always Other information: fedora rawhide evolution-2.5.90-1 gtkhtml3-3.9.90-1 evolution-data-server-1.5.90-1
shortening the summary so it is readable in search results
This problem happens in All cjk locale (like LANG=ko_KR. ja_JP and zh_CN.UTF-8)).
It happens also with the French locale fr_FR.UTF-8/fr_FR. It displays the date in the following format "dd.mm.yy" which gives the error message "Invalid Date Value". NOTE: If you modify it into the following one "dd/mm/yy", it works.
*** Bug 331109 has been marked as a duplicate of this bug. ***
confirming because of the duplicates, lowering severity as there is no data loss, raising priority. according to bug 331109 this seems to work when using language English (US).
*** Bug 331231 has been marked as a duplicate of this bug. ***
I think "no data loss" may be a misleading statement here. In order to change a record in any way that has a date currently in it, the dated information (birthdate, anniversary) has to be removed. So you wind up making a decision about what data is more important and having to potentially discard some.
Ubuntu bug about that: https://launchpad.net/distros/ubuntu/dapper/+source/evolution/+bug/32089
*** Bug 332319 has been marked as a duplicate of this bug. ***
Severity critical, this is a crasher. See bug 332319 for another way of reproducing the very same crash. Regarding comment 5: Please note, that most of my LC_* env vars are set to de_DE.UTF-8 -- however, neither LANG nor LC_TIME is. LANG=en_US.UTF-8 LC_TIME=en_GB.UTF-8
using a french locale I've no crash, but evolution goes to a sort of "invalid date value" loop which makes it hard to close the window and impossible to pick a date for a meeting, etc. Should that be a separate bug (some such descriptions have been marked as dup of that one)?
Agreed. This is the crasher part. :) Adjusting summary. Please see bug 332318 for some details on the broken date input/output logic.
Fix committed.
Created attachment 60022 [details] [review] Fixes the bug.
Created attachment 60025 [details] [review] Fixes the bug.
Patch agains evolution-data-server 1.5.911, but this time the error is Invalid Time Value, not Invalid Date Value Locale zh_CN.UTF-8
Did you use the LANG env var to test this, like mentioned in the original report and comment 2? Please note, that after applying the patch this approach now accepts 2 date formats. The first one is %x according to LC_TIME, the second one is the translated string format[2] according to LANG. * The string being accepted by the latter depends on the translation team. According to zh_CN.po of 2.5.91, "%m/%d/%Y" is translated to "%Y-%m-%d". Younker, does this format work? * The string being accepted by %x indeed uses the the same format as en_US on my system, for zh_CN.UTF-8 as well as ko_KR.UTF-8. This format works, right? $ LC_TIME=ko_KR.UTF-8 date "+%x" Does the output of this command differ from LC_TIME=en_US.UTF-8 on your system? Please mention which string you entered, or how you got that warning dialog. As well as the values for LC_TIME and LANG. Anyway, please note that we split up this bug in 2 appropriate issues. This one is supposed to deal with the crash. Can you reproduce the crash after applying the patch? Please feel free to add date format related comments to bug 332318. Thanks.
Hmm, how does this fix the *crash*? Granted, this works around the looping warning dialog without user interaction. And I just tried *really* hard to trigger this again. However, I could not make the Contact Editor crash, no matter which way I tried to trick the UI. :-) The crash seems to be fixed for me as well by this... *shrug*
crash with similar backtrace while testing GARNOME 2.15.91 LANG=C Triggered by File -> New -> Memo, insert invalid value in "Start date" field (in my case "k"), click on another widget of this window, clicking warning dialogue away. A crash occurs when clicking now in the "Memo Content"-Widget. backtrace:
+ Trace 70601
*** Bug 330114 has been marked as a duplicate of this bug. ***
*** Bug 359025 has been marked as a duplicate of this bug. ***
REOPENing. The stacktrace in comment 19 and bug 359025 seem to match, just some slight differences in the arguments. Both with more recent versions, supposed to be fixed. Dudes, can you please have a *close* look at the recent duplicates? In case this actually is a new issue, please reopen bug 359025.
Looking at it.
Sorry, i could not find time to work on this last week. I will try to fix it up asap.
i assume that this is fixed now? it's the same stacktrace as bug 335622 (gtk+ issue).
closing as duplicate, no feedback. please DO reopen if this is still an issue. thanks! *** This bug has been marked as a duplicate of 335622 ***