GNOME Bugzilla – Bug 745265
Segfault in generate_statusbar_lastmodified_message on Windows
Last modified: 2018-06-29 23:38:52 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
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?
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.
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.
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"
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).
"%x %X" returns "2015/02/26 19:28:18". Please use "最終更新: " as the translation for "Last modified on"
Both the crash and missing Japanese translation fixed in the next release. Thanks!
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.