Opened 7 years ago

Last modified 4 years ago

#4743 new defect

wxDatePickerCtrl crashes with some LC_TIME settings

Reported by: swiss_kinkajou Owned by:
Priority: high Milestone:
Component: wxGTK Version: 2.8.x
Keywords: wxDatePickerCtrl wxGTK unicode Cc: swiss_kinkajou, wojdyr, shilbert
Blocked By: Blocking:
Patch: no

Description

When using wxDatePickerCtrl with wxGTK 2.8.7 (Unicode build) Date representation is incorrect (see picture) and may lead to a core dump.

I'have made test with either wxMac 2.8.7 Unicode and wxMSW 2.8.7 (Unicode too) and this problem seems to be specific to wxGTK.

backtrace of gdb (in case of core dump) indicates a
problem with wxAtoi in datectlg.cpp near line 273.

I'have attached a small code for testing purpose

Attachments (3)

wxdatepickerctrl.jpg download (15.4 KB) - added by swiss_kinkajou 7 years ago.
picture of the problem
datepicker_setformat.diff download (812 bytes) - added by wojdyr 6 years ago.
simplification of SetFormat()
datepicker-2.diff download (3.4 KB) - added by wojdyr 6 years ago.

Download all attachments as: .zip

Change History (31)

Changed 7 years ago by swiss_kinkajou

picture of the problem

comment:1 Changed 7 years ago by swiss_kinkajou

Please provide a small (this is important!) patch to a sample
reproducing the problem. Without being able to reproduce the bug
it is difficult to do anything about it.

comment:2 Changed 7 years ago by swiss_kinkajou

oups sorry, here is the sample code :

If you would like to repeat you can change the MyApp::OnInit() function from the hello world sample with the one pasted bellow. And don't forget to add the <wx/datectrl.h> in your include list

....

bool MyApp::OnInit()
{

MyFrame *frame = new MyFrame( _T("wxDatePicker World"), wxPoint(50,50), wxSize(450,340) );


wxBoxSizer* itemBoxSizer = new wxBoxSizer(wxVERTICAL);
add wxDatePicker
wxDatePickerCtrl* itemDatePickerCtrl = new wxDatePickerCtrl( frame, wxID_ANY);

itemBoxSizer->Add(itemDatePickerCtrl, 0, wxGROW|wxALIGN_CENTER_VERTICAL|wxALL, 5);

frame->SetSizer( itemBoxSizer );


frame->Show(TRUE);
SetTopWindow(frame);
return TRUE;

}

/ ....

comment:3 Changed 7 years ago by wojdyr

yes, it can be seen in calendar sample. It crashes on Ctrl-D, when proper LC_TIME is set.

LC_TIME=pl_PL.utf8 ./calendar
Trace/breakpoint trap (core dumped)

wojdyr@ub:~$ LC_TIME=pl_PL.utf8 date +%x
26 mar 2008
wojdyr@ub:~$ LC_TIME=pl_PL.utf8 date
Åšr, 26 mar 2008, 17:57:36 CET

comment:4 Changed 6 years ago by swiss_kinkajou

  • Keywords wxDatePickerCtrl wxGTK unicode added
  • Milestone set to 2.8.8
  • Version set to 2.8.7

comment:5 Changed 6 years ago by wojdyr

  • Milestone 2.8.8 deleted
  • Status changed from new to confirmed
  • Summary changed from wxDatePickerCtrl show strange things to wxDatePickerCtrl crashes with some LC_TIME settings

comment:6 Changed 6 years ago by wojdyr

  • Patch set

I tried to fix it, but I upgraded my system recently and the format of %x in pl_PL that I have now is using only numbers.
swiss_kinkajou: what locale are you using to have the segfault.
In ja_JP.utf8 locale wxDatePickerCtrl shows assertion, and the simplification I made fixes it, but it's a different problem.

swiss_kinkajou: could you test the attached patch?

Changed 6 years ago by wojdyr

simplification of SetFormat()

comment:7 Changed 6 years ago by vadz

  • Patch unset
  • Priority changed from normal to high

This is not really a patch as it surely does break wxDP_SHOWCENTURY handling.

But the bug does need to be fixed as the program at least shouldn't crash. I'd have to generate Polish locale on my system first in order to see it, maybe someone can tell me what does m_format look like (and how does it get set like this) for this locale?

comment:8 Changed 6 years ago by wojdyr

I have another idea how to fix it - when format passed to SetFormat has letters, replace it with ISO format.
This won't change anything with most of locales, but will prevent crashes with the rest of them. It's not trivial to make the picker work with e.g. textual month in the format, so IMO it's the optimal solution.
What do you think?

comment:9 Changed 6 years ago by vadz

I'm sorry, I don't know what to think as I still don't really understand what the problem is, exactly. If you already understand it, could you please explain?

comment:10 Changed 6 years ago by wojdyr

I don't know what exactly was the original problem of swiss_kinkajou, he didn't reply when I was asking about his locale settings.

The problem I could reproduce is that the picker sets the format to "%x", but in SetFormat() it is assumed that day, month and year are given as numbers, what may not be true. In my case month in %x was given as %b (abbreviated name), not number.

comment:11 Changed 6 years ago by swiss_kinkajou

Sorry for delays with replies but I was away from keyboard for some times.

swiss_kinkajou: what locale are you using to have the segfault.

My locale settings are : fr_CH.UTF-8

swiss_kinkajou: could you test the attached patch?

I'have tested your patch and the wxDatePickerCtrl displays now the correct date. But the Year is displayed using 2 digits instead of 4 : ( DD.MM.YY )

comment:12 Changed 6 years ago by wojdyr

  • Patch set


LC_TIME=fr_CH.utf8 date +%x

  1. 06. 08

(with spaces)

LC_TIME=ja_JP.utf8 date +%x
2008年06月18日

I'm attaching a patch that, this time, fixes the problem in fr_CH.

The problem with ja_JP is different - wxDateTime::ParseFormat() doesn't work well with Japanese characters. I'll open a new ticket for it.

Changed 6 years ago by wojdyr

comment:13 Changed 6 years ago by vadz

I've applied the http://trac.wxwidgets.org/attachment/ticket/4743/datepicker-2.diff patch but I still can't reproduce the crash. I did generate the Polish locale files but I only see (Debian Etch)

% LC_ALL=pl_PL.UTF-8 date +%x
2008-06-22
# but Polish locale is installed correctly:
% LC_ALL=pl_PL.UTF-8 date +%B
czerwiec

and the sample works correctly. How comes you have the month in letters in your case?

Anyhow, can anybody please provide backtrace for the crash? Hopefully this would help me to finally understand what's going on.

TIA!

comment:14 Changed 6 years ago by wojdyr

It seems that Polish locale is different in every distro. As I wrote, I upgraded my system some time ago and I also can't reproduce it now.

Did you try fr_CH? It shows the original problem -- spaces in the format.

comment:15 Changed 6 years ago by swiss_kinkajou

Did you try fr_CH? It shows the original problem -- spaces in the format.

I have applied and tested your patch http://trac.wxwidgets.org/attachment/ticket/4743/datepicker-2.diff and with fr_CH it seems to works perfectly.

Thanks

comment:16 follow-up: Changed 6 years ago by vadz

  • Status changed from confirmed to infoneeded_new

Sorry for repeating the same thing over and over again but does anybody have a way to reproduce the crash? Or at least the gdb stack trace mentioned in the report?

comment:17 in reply to: ↑ 16 Changed 4 years ago by shilbert

  • Cc shilbert added
  • Status changed from infoneeded_new to new
  • Version changed from 2.8.7 to 2.8.x

Replying to vadz:

Sorry for repeating the same thing over and over again but does anybody have a way to reproduce the crash? Or at least the gdb stack trace mentioned in the report?

Here is a way to reproduce it :-)

Install Ubuntu 10.10 (same problem on Debian Squeeze)

set the locale to en_IN (I also have timezone Asia/Kolkatta but it seems to make no difference)

download the wxpython demos for 2.8.11 from wxpython.org

run it and select the datepickerctrl. The demo app will segfault

run the datepickerctrl seperately and it will open and show a strange representation of todays date

workaround:

set the locale to en_US,log out, log in, start the datepickerctrl again. Observe correct output.

I have all this ready to reproduce in an Ubuntu vmware image if that helps.

comment:18 follow-up: Changed 4 years ago by vadz

FWIW I still don't see it under Debian with 2.9 calendar sample so must have been fixed in 2.9.

comment:19 in reply to: ↑ 18 Changed 4 years ago by shilbert

Replying to vadz:

FWIW I still don't see it under Debian with 2.9 calendar sample so must have been fixed in 2.9.

Good to hear. That should make it possible to fix it in 2.8, right ?

Unfortunately I cannot find any packages for Debian yet. It would be great if the issue could be fixed in 2.8.x since Debian will likely ship that for some time.

comment:20 follow-up: Changed 4 years ago by wojdyr

I can see it on Ubuntu, in calendar sample

wx2.9 svn:
Friday 18 March 2011

wxGTK-2.8.12-rc2:
Monday182011October20112011

comment:21 in reply to: ↑ 20 ; follow-ups: Changed 4 years ago by vadz

Replying to wojdyr:

I can see it on Ubuntu, in calendar sample

wx2.9 svn:
Friday 18 March 2011

Could you please show the backtrace? Also, what exactly are you doing in the sample? I just press Ctrl+D, press the drop down arrow and then select another date. Is something else/more needed to trigger the bug?

comment:22 in reply to: ↑ 21 Changed 4 years ago by shilbert

Replying to vadz:

Replying to wojdyr:

I can see it on Ubuntu, in calendar sample

wx2.9 svn:
Friday 18 March 2011

Could you please show the backtrace? Also, what exactly are you doing in the sample? I just press Ctrl+D, press the drop down arrow and then select another date. Is something else/more needed to trigger the bug?

All I am doing is starting the sample. It will then *not* show e.g. 18/03/2011 but something like Monday1820112011Ubu.

I have this ready to go in a vmware virtual machine which has a fresh installation of Ubuntu 10.10. Let me know if you want this or let me know how to provide a backtrace.

comment:23 follow-up: Changed 4 years ago by vadz

  • Patch unset

AFAIU you're using 2.8 which could well be buggy, the code there is very suspicious. Or do you also see the crash with 2.9?

In any case, to provide a backtrace you simply need to run the program under gdb and type "bt" when it crashes.

comment:24 in reply to: ↑ 23 Changed 4 years ago by shilbert

Replying to vadz:

AFAIU you're using 2.8 which could well be buggy, the code there is very suspicious. Or do you also see the crash with 2.9?

Sorry if I introduced noise here. Just to clarify. I am talking about wxpython (if that matters).
And there are two issues:

1.) Sometimes it segfaults
2.) it show a misrepresented (wrong date)

ad 2.)
Since you are not seeing the problem in your setup (Debian) and wojdyr can see it I wonder what locale you have tried.

For wxpython here is a simpler test case:

in a shell type:

export LC_ALL=en_IN
python DatePickerCtrl.py

ad 1.)

It segfaulted once but not again so I can't get a trace.

I have not tried 2.9 Should I open a seperate report on a wrong date issue (as opposed to the crash issue)

comment:25 Changed 4 years ago by shilbert

Runnig it a couple times it segfaulted again:

Program received signal SIGSEGV, Segmentation fault.
0xb7cab153 in strtol_l_internal () from /lib/libc.so.6

#0 0xb7cab153 in strtol_l_internal () from /lib/libc.so.6
#1 0xb7caaf07 in strtol () from /lib/libc.so.6
#2 0xb73b8c05 in wxAtoi(wchar_t const*) () from /usr/lib/wx-2.8-stl/libwx_baseu-2.8.so.0
#3 0xb7866d52 in wxCalendarComboPopup::SetFormat(wchar_t const*) () from /usr/lib/wx-2.8-stl/libwx_gtk2u_adv-2.8.so.0
#4 0xb78678f8 in wxCalendarComboPopup::Create(wxWindow*) () from /usr/lib/wx-2.8-stl/libwx_gtk2u_adv-2.8.so.0
#5 0xb76724a3 in wxComboCtrlBase::CreatePopup() () from /usr/lib/wx-2.8-stl/libwx_gtk2u_core-2.8.so.0
#6 0xb76727c8 in wxComboCtrlBase::DoSetPopupControl(wxComboPopup*) () from /usr/lib/wx-2.8-stl/libwx_gtk2u_core-2.8.so.0
#7 0xb7864616 in wxDatePickerCtrlGeneric::Create(wxWindow*, int, wxDateTime const&, wxPoint const&, wxSize const&, long, wxValidator const&, wxString const&) ()

from /usr/lib/wx-2.8-stl/libwx_gtk2u_adv-2.8.so.0

#8 0xb5fcedb7 in ?? () from /usr/lib/python2.7/site-packages/wx-2.8-gtk2-unicode/wx/_controls_.so
#9 0xb7eca795 in PyCFunction_Call () from /usr/lib/libpython2.7.so.1.0
#10 0xb7edc3a3 in PyEval_EvalFrameEx () from /usr/lib/libpython2.7.so.1.0
#11 0xb7edfe5f in PyEval_EvalCodeEx () from /usr/lib/libpython2.7.so.1.0
#12 0xb7ec3cb9 in ?? () from /usr/lib/libpython2.7.so.1.0
#13 0xb7ebeb40 in PyObject_Call () from /usr/lib/libpython2.7.so.1.0
#14 0xb7ebf9c0 in ?? () from /usr/lib/libpython2.7.so.1.0
#15 0xb7ebeb40 in PyObject_Call () from /usr/lib/libpython2.7.so.1.0
#16 0xb7ed02c0 in ?? () from /usr/lib/libpython2.7.so.1.0
#17 0xb7ecfb6a in ?? () from /usr/lib/libpython2.7.so.1.0
#18 0xb7ebeb40 in PyObject_Call () from /usr/lib/libpython2.7.so.1.0
#19 0xb7eda503 in PyEval_EvalFrameEx () from /usr/lib/libpython2.7.so.1.0
#20 0xb7edfe5f in PyEval_EvalCodeEx () from /usr/lib/libpython2.7.so.1.0
#21 0xb7ec3a07 in ?? () from /usr/lib/libpython2.7.so.1.0
#22 0xb7ebeb40 in PyObject_Call () from /usr/lib/libpython2.7.so.1.0
#23 0xb7ebf9c0 in ?? () from /usr/lib/libpython2.7.so.1.0
#24 0xb7ebeb40 in PyObject_Call () from /usr/lib/libpython2.7.so.1.0
#25 0xb7ed02c0 in ?? () from /usr/lib/libpython2.7.so.1.0
#26 0xb7ecfb6a in ?? () from /usr/lib/libpython2.7.so.1.0
#27 0xb7ebeb40 in PyObject_Call () from /usr/lib/libpython2.7.so.1.0
#28 0xb7eda503 in PyEval_EvalFrameEx () from /usr/lib/libpython2.7.so.1.0
#29 0xb7edc605 in PyEval_EvalFrameEx () from /usr/lib/libpython2.7.so.1.0
#30 0xb7ee0009 in PyEval_EvalCodeEx () from /usr/lib/libpython2.7.so.1.0
#31 0xb7ec3a07 in ?? () from /usr/lib/libpython2.7.so.1.0
#32 0xb7ebeb40 in PyObject_Call () from /usr/lib/libpython2.7.so.1.0
#33 0xb7ebf9c0 in ?? () from /usr/lib/libpython2.7.so.1.0
#34 0xb7ebeb40 in PyObject_Call () from /usr/lib/libpython2.7.so.1.0
#35 0xb7ed89f6 in PyEval_CallObjectWithKeywords () from /usr/lib/libpython2.7.so.1.0
#36 0xb78fab97 in wxPyApp::_BootstrapApp() () from /usr/lib/python2.7/site-packages/wx-2.8-gtk2-unicode/wx/_core_.so
#37 0xb7988401 in ?? () from /usr/lib/python2.7/site-packages/wx-2.8-gtk2-unicode/wx/_core_.so
#38 0xb7eca7b0 in PyCFunction_Call () from /usr/lib/libpython2.7.so.1.0
#39 0xb7edc3a3 in PyEval_EvalFrameEx () from /usr/lib/libpython2.7.so.1.0
#40 0xb7edfe5f in PyEval_EvalCodeEx () from /usr/lib/libpython2.7.so.1.0
#41 0xb7ed9e8e in PyEval_EvalFrameEx () from /usr/lib/libpython2.7.so.1.0
#42 0xb7ee0009 in PyEval_EvalCodeEx () from /usr/lib/libpython2.7.so.1.0
#43 0xb7ec3cb9 in ?? () from /usr/lib/libpython2.7.so.1.0
#44 0xb7ebeb40 in PyObject_Call () from /usr/lib/libpython2.7.so.1.0
#45 0xb7ebf9c0 in ?? () from /usr/lib/libpython2.7.so.1.0
#46 0xb7ebeb40 in PyObject_Call () from /usr/lib/libpython2.7.so.1.0
#47 0xb7eda503 in PyEval_EvalFrameEx () from /usr/lib/libpython2.7.so.1.0
#48 0xb7edfe5f in PyEval_EvalCodeEx () from /usr/lib/libpython2.7.so.1.0
#49 0xb7ec3a07 in ?? () from /usr/lib/libpython2.7.so.1.0
#50 0xb7ebeb40 in PyObject_Call () from /usr/lib/libpython2.7.so.1.0
#51 0xb7ebf9c0 in ?? () from /usr/lib/libpython2.7.so.1.0
#52 0xb7ebeb40 in PyObject_Call () from /usr/lib/libpython2.7.so.1.0
#53 0xb7ed02c0 in ?? () from /usr/lib/libpython2.7.so.1.0
#54 0xb7ecfb6a in ?? () from /usr/lib/libpython2.7.so.1.0
#55 0xb7ebeb40 in PyObject_Call () from /usr/lib/libpython2.7.so.1.0
#56 0xb7eda503 in PyEval_EvalFrameEx () from /usr/lib/libpython2.7.so.1.0
#57 0xb7edc605 in PyEval_EvalFrameEx () from /usr/lib/libpython2.7.so.1.0
#58 0xb7ee0009 in PyEval_EvalCodeEx () from /usr/lib/libpython2.7.so.1.0
#59 0xb7f0f663 in PyEval_EvalCode () from /usr/lib/libpython2.7.so.1.0
#60 0xb7f1db1c in ?? () from /usr/lib/libpython2.7.so.1.0
#61 0xb7f1dfde in PyRun_FileExFlags () from /usr/lib/libpython2.7.so.1.0
#62 0xb7f1e77b in PyRun_SimpleFileExFlags () from /usr/lib/libpython2.7.so.1.0
#63 0xb7f1ed1a in PyRun_AnyFileExFlags () from /usr/lib/libpython2.7.so.1.0
#64 0xb7f283a7 in Py_Main () from /usr/lib/libpython2.7.so.1.0
#65 0x08048687 in main ()

comment:26 Changed 4 years ago by vadz

I'm using en_IN under Debian but I'm only testing with 2.9, unfortunately I don't have the possibility to work on 2.8 any more.

comment:27 in reply to: ↑ 21 ; follow-up: Changed 4 years ago by wojdyr

Replying to vadz:

Replying to wojdyr:

I can see it on Ubuntu, in calendar sample

wx2.9 svn:
Friday 18 March 2011

Could you please show the backtrace?

Sorry for the unclear post.
I meant that I do NOT see this bug in 2.9, only in 2.8 (which is to be expected if the changes discussed earlier in this ticket have not been backported).
Everything is fine in 2.9.

comment:28 in reply to: ↑ 27 Changed 4 years ago by shilbert

Replying to wojdyr:

Replying to vadz:

Replying to wojdyr:

I can see it on Ubuntu, in calendar sample

wx2.9 svn:
Friday 18 March 2011

Could you please show the backtrace?

Sorry for the unclear post.
I meant that I do NOT see this bug in 2.9, only in 2.8 (which is to be expected if the changes discussed earlier in this ticket have not been backported).
Everything is fine in 2.9.

If there is a fix in 2.9 I sure hope someone backports it to 2.8 since this is the stable release and shiped as default by many distributions.

Note: See TracTickets for help on using tickets.