GNOME Bugzilla – Bug 755920
Crash (Freeze) when using File Save As.. in Windows OS
Last modified: 2018-06-29 23:43:22 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.
Created attachment 312467 [details] Trace from freeze while save as
I can reproduce this in the debugger, here's the top of the stack trace.
+ Trace 235540
Thread 1 (Thread 4644.0xc28)
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.
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.
*** Bug 755960 has been marked as a duplicate of this bug. ***
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.
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.
This problem has been fixed in our software repository. The fix will go into the next software release, which will probably be quite soon.
*** Bug 755996 has been marked as a duplicate of this bug. ***
*** Bug 756037 has been marked as a duplicate of this bug. ***
*** Bug 756066 has been marked as a duplicate of this bug. ***
*** Bug 756102 has been marked as a duplicate of this bug. ***
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.