GNOME Bugzilla – Bug 507865
date->string conversion crash in reports
Last modified: 2018-06-29 21:58:49 UTC
Steps to reproduce: 1. Defaults put "Today Date Format" in "Vendor Report" General tab as "%B %e, %Y" 2. Apparently, %e there is what's causing crash. 3. Changing %e to %d displays date normally without a crash. 4. Could be a problem in some other report options dialogs - don't have data there yet to make sure Stack trace: Faulting application gnucash-bin.exe, version 0.0.0.0, time stamp 0x47673898, faulting module libgncmod-engine.dll, version 6.0.6000.16386, time stamp 0x4549bdc9, exception code 0xc0000135, fault offset 0x00008fc7, process id 0x1218, application start time 0x01c851511d17c120. Other information: No stack trace - information above from Windows Vista application event log. Bug is obvious and is probably easy to find and fix.
It is unclear from your report exactly what is happening here. It *sounds* like you are saying that using the default %e date format causes the whole application to crash. But the %d date format does not cause this crash. Is that correct? And is this reliably reproducible? Can you try this in the other reports that use that date format: Easy Invoice and Printable Invoice, and report your results? retitling.
That is exactly what I meant - you understood it correctly. It is reproducible reliably - happens every time. If I remove %e (or replace it with %d) and leave other placeholders intact (or add some others, like %H %M %S) it doesn't crash. By the way, I failed to locate anywhere in the help a list for legitimate placeholders to use in that field. I just checked other reports: - Printable invoice - exactly same behavior as above - Easy invoice - doesn't happen. I guess it's due to the fact that it (today's date) is not used in that report at all! In other words, I can remove the pattern, change it, leave it as is; no today's date is put anywhere on that "Easy invoice". Therefore, no crash.
The format strings appear to be the same as those in the date program found on linux systems. Can you test using the format string "%_d" and see if you get the same behavior? I'm guessing this may turn out to be 1) a windows only issue and 2) may be a locale related issue. What locale?
The "%_d" causes crash as well. My system is Windows Vista Business, locale: en-US. I did not do any compilations - just downloaded Windows binaries. Currently using the newest one, which behaves same in this regard as the previous. Here's the copy of the About dialog: gnucash 2.2.3 The GnuCash personal finance manager. The GNU way to manage your money! This copy was built from r16843 on 2008-01-08.
Okay, thanks Sergei. I'm retagging this to windows as that is almost surely where it belongs. Just to sum up, the formatting parameters for the date are broken for space-padded representations of the day, either %e or %_d. I'm also willing to bet this problem may be external to GnuCash, but I don't know windows. Meanwhile, since it's an app crasher, I'll patch svn and ask for backport to change the default date formats to %d to prevent data loss. Anyone disagree?
Yes, I want to take a look at it first. Feel free to attach a patch for it if you feel the pressing need :-) Milestoning 2.2.4.
(In reply to comment #2) > By the way, I failed to locate anywhere in the help a list for legitimate > placeholders to use in that field. You may want to check out http://msdn2.microsoft.com/en-us/library/fe06s4ak(VS.71).aspx Does not crash on Windows XP, BTW.
Thanks for the link - apparently, %e option is not in the list there. I have Windows XP Pro SP2 laptop, so I installed v2.2.3 just now to check. Indeed, it doesn't crash. However, it doesn't show the actual day part either. So it just ignores it, apparently. Does show it if I use "%d" though.
Oops :-) m -> 2.2.5 (for now ;-))
Oops, missed that one. Adding to the list for 2.2.6 (now 2, you are not alone).
%d is usable everywhere, but it is incorrect because it 0-pads days 1-9 (so you get "May 01, 2008" instead of "May 1, 2008"). %e only works on Linux/Unix. %_d works on linux, but %#d works on Windows. Yay standards. :(
Closing this bug as "fixed" since the application no longer crashes when %e is used. On a related note, the default format on win32 platforms will now be %#d (rather than %e) as of r17250 (see bug 520361, bug 530924, bug 532405).
(In reply to comment #12) > Closing this bug as "fixed" since the application no longer crashes when %e is > used. How come? I am sorry for reopening, but I simply do not understand :-) If there is still something to be backported for this bug, either make this dependent on another bug, or block backport and tell me the revision.
I closed this one because %e is not supported on Windows platforms. I am saying that this bug has been fixed because the application no longer crashes if a user tries to use %e. Instead, the report displays an error message. I guess I am separating two things: 1. Support for %e on Windows, which we cannot do, but can at least not crash. 2. Not using %e in the default date format on reports. (Covered in bug 532405)
Now that bug 532405 has been fixed, it seems like this bug only remains open because Vista crashes if the user tries to use %e. Is this something we can do anything about, and if so, what needs to be done?
Does entering %e on Vista still cause a crash when using GnuCash 2.2.6? (Make sure to enter %e manually, as %#d is now the default.)
I just got an email regarding this bug, I assume, because I was the one reporting it originally and its status now is NEEDINFO. Unfortunately, I quit using gnucash quite a while ago so I can't help with it anymore. Sorry.
OK, thanks Sergei. I will close this one as INCOMPLETE.
GnuCash bug tracking has moved to a new Bugzilla host. This bug has been copied to https://bugs.gnucash.org/show_bug.cgi?id=507865. Please update any external references or bookmarks.