After an evaluation, GNOME has moved from Bugzilla to GitLab. Learn more about GitLab.
No new issues can be reported in GNOME Bugzilla anymore.
To report an issue in a GNOME project, go to GNOME GitLab.
Do not go to GNOME Gitlab for: Bluefish, Doxygen, GnuCash, GStreamer, java-gnome, LDTP, NetworkManager, Tomboy.
Bug 745265 - Segfault in generate_statusbar_lastmodified_message on Windows
Segfault in generate_statusbar_lastmodified_message on Windows
Status: RESOLVED FIXED
Product: GnuCash
Classification: Other
Component: Windows
2.6.5
Other Windows
: Normal normal
: ---
Assigned To: John Ralls
gnucash-win-maint
Depends on:
Blocks:
 
 
Reported: 2015-02-27 00:44 UTC by Kasumi Hanazuki
Modified: 2018-06-29 23:38 UTC
See Also:
GNOME target: ---
GNOME version: ---



Description Kasumi Hanazuki 2015-02-27 00:44:48 UTC
I'm investigating the problem reported on the user list <http://lists.gnucash.org/pipermail/gnucash-user/2015-February/058685.html>, and found it seems to be caused by a segfault in `generate_statusbar_lastmodified_message'.

I think the problem is that g_date_time_format(gdt, "%P") returns NULL (I don't know the reason). Therefore, strlen(dummy_strftime_has_ampm) segfaults.
Indeed, `g_date_time_format(gnc_g_date_time_new_from_unix_local(1424946498),"%P")` evaluates to NULL on gdb.

My environemnt:
- OS: Windows 7 SP1 (x64) Japanese
- TZ: UTC+9 (JST)
- Gnucash 2.6.5 (official stable build)

Local variables:
		mtime	1424946498	gint64
+		gdt	0x8cdfa88	GDateTime *
+		dummy_strftime_has_ampm	0x0	gchar *
+		time_string	0x6f47e08 ""	gchar *
+		statbuf	{...}	struct stat
		r	0	int
+		filepath	0xa562600 "C:\Users\Kasumi\Desktop\kakeibo.gnucash"	gchar *
+		filename	0x8e5e0c0 "kakeibo.gnucash"	gchar *
+		message	0x0	gchar *
+		book_id	0x8e35cb8 "file://C:\Users\Kasumi\Desktop\kakeibo.gnucash"	const gchar *

Stack trace:
>	gnucash.exe!generate_statusbar_lastmodified_message(  ) Line 1668	c
 	gnucash.exe!statusbar_notification_lastmodified(  ) Line 1716	c
 	gnucash.exe!gnc_main_window_restore_all_windows( 0x6fc7b48 ) Line 936	c
 	gnucash.exe!gnc_restore_all_state( 0x8e357e8, 0x0 ) Line 282	c
 	gnucash.exe!call_c_hook( 0x8e221a0, 0x8e221a0, 0x8e357e8, 0x8e357e8 ) Line 217	c
 	gnucash.exe!g_hook_list_marshal( 0x7020f00, 1, 0x635be328 <call_c_hook>, 0x8e357e8 ) Line 676	c
 	gnucash.exe!gnc_hook_run( 0x20c0b04 <__PRETTY_FUNCTION__.88508+4068> "hook_book_opened", 0x8e357e8 ) Line 233	c
 	gnucash.exe!gnc_book_opened(  ) Line 509	c
 	gnucash.exe!gnc_post_file_open( 0x8e36710 "C:\Users\Kasumi\Desktop\kakeibo.gnucash", 1 ) Line 990	c
 	gnucash.exe!gnc_file_open_file( 0x8e36710 "C:\Users\Kasumi\Desktop\kakeibo.gnucash", 0 ) Line 1057	c
 	gnucash.exe!inner_main( 0x0, 1, 0x350b6f8 ) Line 608	c
 	gnucash.exe!invoke_main_func( 0x28fed0 ) Line 367	c
 	gnucash.exe!c_body( 0x28fe54 ) Line 349	c
 	gnucash.exe!scm_c_catch( 0x104, 0x104, 0x6bf84a80 <c_body>, 0x6bf84a80 <c_body>, 0x28fe54, 0x28fe54, 0x6bf84aa0 <c_handler>, 0x6bf84aa0 <c_handler>, 0x28fe54, 0x28fe54, 0x6bfe4f20 <scm_handle_by_message_noexit>, 0x6bfe4f20 <scm_handle_by_message_noexit>, 0x0, 0x0 ) Line 203	c
 	gnucash.exe!scm_i_with_continuation_barrier( 0x6bf84a80 <c_body>, 0x6bf84a80 <c_body>, 0x28fe54, 0x28fe54, 0x6bf84aa0 <c_handler>, 0x6bf84aa0 <c_handler>, 0x28fe54, 0x28fe54, 0x6bfe4f20 <scm_handle_by_message_noexit>, 0x0, 0x0 ) Line 325	c
 	gnucash.exe!scm_c_with_continuation_barrier( 0x6bfab2f0 <invoke_main_func>, 0x6bfab2f0 <invoke_main_func>, 0x28fed0, 0x28fed0 ) Line 367	c
 	gnucash.exe!scm_i_with_guile_and_parent( 0x6bfab2f0 <invoke_main_func>, 0x6bfab2f0 <invoke_main_func>, 0x28fed0, 0x28fed0, 0x0 ) Line 733	c
 	gnucash.exe!scm_with_guile( 0x6bfab2f0 <invoke_main_func>, 0x6bfab2f0 <invoke_main_func>, 0x28fed0, 0x28fed0 ) Line 721	c
 	gnucash.exe!scm_boot_guile( 1, 0x350b6f8, 0x40326b <inner_main>, 0x0 ) Line 350	c
 	gnucash.exe!main( 1, 0x350b6f8 ) Line 776	c
Comment 1 John Ralls 2015-02-27 16:54:53 UTC
Good catch. I imagine that this is a localization issue, that Japanese doesn't have a before-noon or after-noon designator for 12-hour times. The obvious fix is to check dummy_strftime_for_ampm for being NULL as well as for being an empty string, but I wonder if the test is even necessary. Does 
 g_date_time_format (gdt, "Last modified on %a, %b %e, %Y at %I:%M%P")
produce a correct string?
Comment 2 Kasumi Hanazuki 2015-02-27 22:45:31 UTC
Here's some evaluations.

g_date_time_format (gdt, "Last modified on %a, %b %e, %Y at %I:%M%P") -> NULL
g_date_time_format (gdt, "Last modified on %F %T") -> "Last modified on 2015-02-26 19:28:18"

g_date_time_format (gdt, "%a") -> "\xE8\xAD\x9B\xEF\xBD\xA8\0"
g_date_time_format (gdt, "%b") -> NULL
g_date_time_format (gdt, "%e") -> "26"
g_date_time_format (gdt, "%Y") -> "2015"
g_date_time_format (gdt, "%I") -> "07"
g_date_time_format (gdt, "%M") -> "28"
g_date_time_format (gdt, "%P") -> NULL

The result for %a looks like a utf8 sequence and decodes to a nonsense "譛ィ".
In Shift_JIS "譛ィ" is "\xE6\x9C\xA8", which can decodes to "木" (Thursday) in utf8.
So I doubt there's some charset handling issue.
Comment 3 John Ralls 2015-02-28 03:55:02 UTC
It's that first bit that I was wondering about. Having the %P in the format appears to cause g_date_time_format() to fail. To make sure, please try 
   g_date_time_format (gdt, "Last modified on %a, %b %e, %Y at %I:%M")

As for encoding, that's dependent upon the locale setting and the code-page. It's a real pain to get the right combination on Win32 when working from the terminal.
Comment 4 Kasumi Hanazuki 2015-02-28 04:03:32 UTC
It also returns NULL.

g_date_time_format (gdt, "Last modified on %a, %b %e, %Y at %I:%M") -> NULL

g_date_time_format (gdt, "Last modified on %a, %e, %Y at %I:%M%P") -> NULL
g_date_time_format (gdt, "Last modified on %a, %e, %Y at %I:%M") -> "Last modified on \xE8\xAD\x9B\xEF\xBD\xA8, 26, 2015 at 07:28"
Comment 5 John Ralls 2015-02-28 16:34:59 UTC
Hmm. Not very useful without the month, is it? I guess Japanese doesn't have month names, only numbers.

Does "%x %X" work? It's supposed to be the preferred date and time representation for the current locale. I'm inclined to go with that. The alternative is that the whole string, format and all, is localized though it's not translated in ja.po, so I could remove the conditional and use the first format for the C local, which would make Americans happier (they tend not to like 24-hour times) and fix it everywhere else in the translations. That has the downside that it might still fail if a locale isn't translated because string translation and date localization are separate.

What's Japanese for "Last modified on"? (UTF8, please, so I can just paste it into ja.po).
Comment 6 Kasumi Hanazuki 2015-02-28 22:42:13 UTC
"%x %X" returns "2015/02/26 19:28:18".

Please use "最終更新: " as the translation for "Last modified on"
Comment 7 John Ralls 2015-03-11 08:07:09 UTC
Both the crash and missing Japanese translation fixed in the next release. Thanks!
Comment 8 John Ralls 2018-06-29 23:38:52 UTC
GnuCash bug tracking has moved to a new Bugzilla host. This bug has been copied to https://bugs.gnucash.org/show_bug.cgi?id=745265. Please update any external references or bookmarks.