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 755920 - Crash (Freeze) when using File Save As.. in Windows OS
Crash (Freeze) when using File Save As.. in Windows OS
Status: RESOLVED FIXED
Product: GnuCash
Classification: Other
Component: User Interface General
2.6.8
Other Windows
: Normal critical
: ---
Assigned To: gnucash-ui-maint
gnucash-ui-maint
: 755960 755996 756037 756066 756102 (view as bug list)
Depends on:
Blocks:
 
 
Reported: 2015-10-01 08:24 UTC by David Carlson
Modified: 2018-06-29 23:43 UTC
See Also:
GNOME target: ---
GNOME version: ---


Attachments
Trace from freeze while save as (351 bytes, text/plain)
2015-10-01 08:26 UTC, David Carlson
Details

Description David Carlson 2015-10-01 08:24:19 UTC
Happens in Windows 7 on my machine and others reported it happens in Windows 10.   The weekly build 2.6.7 built from git rev 766cf48+ on 2015-09-18 on my machine and Release 2.6.8 both freeze when using File Save As...

I am attaching the trace file.  There are a couple of oddities in it.
Comment 1 David Carlson 2015-10-01 08:26:38 UTC
Created attachment 312467 [details]
Trace from freeze while save as
Comment 2 John Ralls 2015-10-01 16:42:25 UTC
I can reproduce this in the debugger, here's the top of the stack trace.

Thread 1 (Thread 4644.0xc28)

  • #0 ntdll!RtlInitUnicodeString
    from C:\Windows\SysWOW64\ntdll.dll
  • #1 ??
  • #2 ntdll!RtlAllocateHeap
    from C:\Windows\SysWOW64\ntdll.dll
  • #3 msvcrt!malloc
    from C:\Windows\syswow64\msvcrt.dll
  • #4 g_malloc
    at ../../glib/gmem.c line 104
  • #5 g_path_get_dirname
    at ../../glib/gfileutils.c line 2446
  • #6 check_file_path
  • #7 gnc_file_do_save_as
  • #8 gnc_ui_file_access_response_cb
  • #9 _g_closure_invoke_va
    at ../../gobject/gclosure.c line 840

Comment 3 Geert Janssens 2015-10-01 17:47:24 UTC
Your most likely candidate to have introduced is this commit:
https://github.com/Gnucash/gnucash/commit/7d940a5d91729c8834808a6d5fd9a1e956eaa80f

I'm not sure the while loop in check_file_path will ever end on Windows. The root directory there is not '/'. You may want to save the default_dir and compare the new default_dir to this saved version after calling g_path_get_dirname. If both are the same you have reached the toplevel directory and should exit the while loop.

FYI, I'm in the process of "bisecting" the weekly builds as found on the build server. Have to pause now because I have to leave. But so far all builds as of 2015-07-11 are bad while the build on 2015-06-28 is good. There are only 3 builds left to test in between if you want more precise root cause detection.
Comment 4 John Ralls 2015-10-01 17:56:01 UTC
Thanks! I was just starting that process, you've saved me a lot of time. I think your diagnosis is likely correct as well, so I'll check that as a first step.
Comment 5 John Ralls 2015-10-01 21:08:33 UTC
*** Bug 755960 has been marked as a duplicate of this bug. ***
Comment 6 Geert Janssens 2015-10-02 09:40:37 UTC
At what point did you take your stack trace ?

Had you set a breakpoint in check_file_path ? I don't see signs of that because the program is halted deep into some system libary.

Or did you wait until gnucash was in its infinite loop and then interrupted the program ?

I'm asking because I'm surprised that your stack trace still shows an intermediate path of "\\\\vmware-host\\Shared Folders\\" as input to g_get_dirname.

If you got your stack trace by interrupting gnucash I would have expected the loop to have iterated sufficiently to reduce the intermediate path to nothing. Unless g_path_get_dirname is more intelligent than I assumed and is aware of network shares and stops iterating as soon as it hits the mount point of the share.
Comment 7 John Ralls 2015-10-02 13:59:58 UTC
Don't worry, your diagnosis was correct. I have one more test to run, as long as it passes I'll commit a fix today. \\\\vmware-host\\Shared Folders\\ is a drive id, not a mount point. g_path_get_dirname understands that, see the comment in https://git.gnome.org/browse/glib/tree/glib/gfileutils.c starting at line 2356.
Comment 8 John Ralls 2015-10-02 16:20:36 UTC
This problem has been fixed in our software repository. The fix will go into the next software release, which will probably be quite soon.
Comment 9 John Ralls 2015-10-02 20:49:03 UTC
*** Bug 755996 has been marked as a duplicate of this bug. ***
Comment 10 John Ralls 2015-10-04 13:43:52 UTC
*** Bug 756037 has been marked as a duplicate of this bug. ***
Comment 11 John Ralls 2015-10-05 00:00:44 UTC
*** Bug 756066 has been marked as a duplicate of this bug. ***
Comment 12 John Ralls 2015-10-06 02:22:08 UTC
*** Bug 756102 has been marked as a duplicate of this bug. ***
Comment 13 John Ralls 2018-06-29 23:43:22 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=755920. Please update any external references or bookmarks.