GNOME Bugzilla – Bug 521817
Guid_init causes very long startup delay if Novell Network active
Last modified: 2018-06-29 22:02:11 UTC
Steps to reproduce: 1. Installed the application (tried with 2.2.0, 2.2.3, 2.2.4) 2. Start the application 3. Stops after showing "Tip of the day" and other screen stops loading. At the bottom where the components are shown being loaded, it stops at : gnucash/apps-utils Stack trace: I installed mingw gdb and modified the batch file that starts gnucash to start gdb and followed all the instructions. Unfortunately, when I type BT, I get a "no stack" message. If someone can tell me what I am doing wrong, I am more than willing to help get any trace. Other information: I have installed this software successfully on a Windows XP Home SP2 edition OS. Everything works fine there. When I try to run it on my laptop which is a Windows XP PRO SP2, it does not. Also, this laptop is part of a domain. Whether I am attached to the domain or not makes no difference. I also tried with a local Administrator account.
Created attachment 107078 [details] Some file that is sent to microsoft when the application crashes
Hello, It seems that I was never "patient" enough. The application does hang at this point, until...... 15 minutes later (!)... it comes up to the screen. I have a fast enough laptop that does justify this wait (AMD 64 X2(dual core) Turion TL-60 2Ghz with 2 GB RAM). I am a power user and I have plenty of applications that are running fine on this device. I still can't get the backtrace for gdp. Joffrey
Is that still true for GnuCash 2.2.7?
Unfortunately, yes. Actually, since 2.2.5, even it won't start (unlike the 2.2.4 version)
What about if I try compiling the source? What do I need to download/install? gcc ? and what else? Thanks Joffrey
See http://wiki.gnucash.org/wiki/Windows . Is the application able to open a file after the long waiting time? If yes, this is a duplicate of bug #518620
It is not opening at all since version 2.2.4. It hangs on the splash screen and the "Tip of the Day" window.
*** Bug 551888 has been marked as a duplicate of this bug. ***
*** Bug 531306 has been marked as a duplicate of this bug. ***
From bug#508727: What happens if you * run a windows session without having started gnucash yet (so that it would hang) * start > run... > cmd.exe * cd $PREFIX\bin ($PREFIX might be C:\Program Files\GnuCash) * gconftool-2.exe --spawn (how long does it take until the prompt is printed? is gconfd-2.exe running in the task manager?) * gconftool-2 --ping * echo %errorlevel% (is it 0 or 2?) Do you run other Gconf or GTK+ based programs? Does running 'gconftool-2.exe --shutdown' before starting GnuCash change anything? Does it make GnuCash hang after it has started successfully once (assuming the second startup is snappy normally)?
*** Bug 561760 has been marked as a duplicate of this bug. ***
(In reply to comment #4) > Unfortunately, yes. Actually, since 2.2.5, even it won't start (unlike the > 2.2.4 version) I have the same problem now with version 2.2.8.
I have the same problem with the newest version (2.3.5)
Thanks for Your help, but my problems are solved now with the latest version of the program.
I am still having the same problem. gconftool-2.exe --shutdown did not do anything
I was wondering if this is specific to Windows XP Professional...? Anyone running Win XP pro and not having an issue?
I tried also with 2.3.8 and problem is still occuring
Could you possibly try the other steps mentioned in comment 14: * run a windows session without having started gnucash yet (so that it would hang) * start > run... > cmd.exe * cd $PREFIX\bin ($PREFIX might be C:\Program Files\GnuCash) * gconftool-2.exe --spawn -> how long does it take until the prompt is printed, on other words how long does this command take to run ? -> is gconfd-2.exe running in the task manager after this command finishes ? * gconftool-2 --ping * echo %errorlevel% (is it 0 or 2?) They won't change the behaviour of your GnuCash run, but it may give us some additional information on where the problem begins.
gconftool-2.exe --spawn takes about 1 or 2 seconds to execute gconftool-2.exe --ping return 0 but gconfd-2.exe dies after about 20 secondes
... so ping will fail afterwards and return 2
*** Bug 508727 has been marked as a duplicate of this bug. ***
Thanks for the info Joffrey. So gconfd-2.exe dies. I'm suspect this is part of the problem. I'll have to hand it to the other devs from here. My Windows knowledge is too limited.
I too am trying to run GNUcash in XP Pro and am having the same problem. I installed 2.2.9 as the latest stable version. Having read the similar issues etc one thing I noticed was asked was if Perl was installed. I do not have perl installed, should I have? I tried installing 2.3.10 but am still having the same issue.
http://lists.gnucash.org/pipermail/gnucash-devel/2011-January/030659.html writes: > I ran Sysinternals Process Monitor while gnucash was starting and found it was going through every file name in the top level direcotry (C:\) and trying to open a reg key based on the name. After going through the entire list of file names, it started within a minute. What is the latest version where people still see this issue?
I'm also still facing this issue with version 2.4 on my company notebook (Win XP Professional Service Pack 2).
(In reply to comment #23) > Thanks for the info Joffrey. > > So gconfd-2.exe dies. I'm suspect this is part of the problem. > Actually this conclusion is wrong. Gconfd is supposed to exit some time after the last program that uses it has quit. What happens if you use a slight variation of the instructions: * run a windows session without having started gnucash yet (so that it would hang) * start > run... > cmd.exe * cd $PREFIX\bin ($PREFIX might be C:\Program Files\GnuCash) * gconftool-2.exe --all-dirs /apps (This should print /apps/gnucash)
(In reply to comment #27) > (In reply to comment #23) > > Thanks for the info Joffrey. > > > > So gconfd-2.exe dies. I'm suspect this is part of the problem. > > > Actually this conclusion is wrong. Gconfd is supposed to exit some time after > the last program that uses it has quit. > > What happens if you use a slight variation of the instructions: > * run a windows session without having started gnucash yet (so that it would > hang) > * start > run... > cmd.exe > * cd $PREFIX\bin ($PREFIX might be C:\Program Files\GnuCash) > * gconftool-2.exe --all-dirs /apps > > (This should print /apps/gnucash) Mine did print "/apps/gnucash" immediately while stuck on loading, but still takes a solid 15 minutes to load. This happens every time I launch GnuCash. It doesn't have to be a fresh boot. I have tested this on three different laptops, all running Win XP Pro SP2. Using Sysinternals Process Monitor, I am also seeing my C:\WINDOWS\system32\drivers\etc\hosts file being queried, UDP/TCP messages, and registry access over and over and over again. This goes on the entire time it is stuck on loading gnucash/apps-utils, and stops once loading is finished.
Thanks for the feedback. The "/apps/gnucash" test was not to determine if you have the problem or not. It was just to determine that gconf could at least be contacted. How about these: * start > run... > cmd.exe * cd "C:\Program Files\GnuCash\bin" * gconftool-2.exe --get-default-source -> What does this output ? * gconftool-2.exe -a /apps/gnucash/history -> What does this output ? * gconftool-2.exe --set --type string /apps/gnucash/history/file9 "Testvalue" * gconftool-2.exe --get /apps/gnucash/history/file9 -> What does this output ? * gconftool-2.exe --set --type string /apps/gnucash/history/file9 "Testvalue" * gconftool-2.exe --unset /apps/gnucash/history/file9 (This one is to remove the test value again) * gconftool-2.exe --get /apps/gnucash/history/file9 -> Is the testvalue gone ? I'm trying to understand what gconf does on systems that experience startup problems. Also, can you attach a Sysinternals Process Monitor output with only the entries for the gnucash.exe and the gconfd-2.exe processes once it gets passed the dead loading period ? Preferably in the proces monitor's native format. I realize this will likely be a large file, but it may hint at what it is doing.
Here are the commands you asked me to run: #### Output Start ### C:\Program Files\gnucash\bin>gconftool-2.exe --get-default-source xml:merged:C:/Program Files/gnucash/etc/gconf/gconf.xml.defaults C:\Program Files\gnucash\bin>gconftool-2.exe -a /apps/gnucash/history file0 = C:\Documents and Settings\tbongior\Desktop\My Dropbox\Account Ledger\Ac count Ledger file1 = C:\Documents and Settings\tbongior\Desktop\My Dropbox\Account Ledger file2 = C:\Documents and Settings\tbongior\Desktop\test file3 = file4 = file5 = file6 = file7 = file8 = file9 = maxfiles = 4 C:\Program Files\gnucash\bin>gconftool-2.exe --set --type string /apps/gnucash/h istory/file9 "Testvalue" C:\Program Files\gnucash\bin>gconftool-2.exe --get /apps/gnucash/history/file9 Testvalue C:\Program Files\gnucash\bin>gconftool-2.exe --set --type string /apps/gnucash/h istory/file9 "Testvalue" C:\Program Files\gnucash\bin>gconftool-2.exe --unset /apps/gnucash/history/file9 C:\Program Files\gnucash\bin>gconftool-2.exe --get /apps/gnucash/history/file9 C:\Program Files\gnucash\bin> #### Output Stop ### I have attached the Sysinternals Process Monitor output from once it gets past the dead loading period. I assume the dead loading period is while it is stuck loading gnucash/apps-utils. The file is in native format (~170KB), but since I had to highlight the events to save, I could not include profiling events. I also have the dead load events (~900KB) and all events with and without profiling events (~20.1MB/~1MB) if you would like them.
Created attachment 182190 [details] Sysinternals Process Monitor output post dead loading period.
Sorry, I may not have expressed myself clearly. I was interested in the events starting when gnucash, including the long period to wait until it resumes loading. So with all the events happening in the dead period. The full logs may be useful as well, but I'm not sure if Bugzilla imposes a file upload size limit. In any case given the size of the files, perhaps you can compress them first.
Created attachment 182195 [details] Sysinternals Process Monitor output during dead loading period.
Comment on attachment 182190 [details] Sysinternals Process Monitor output post dead loading period. Did not include gconfd.exe.
Comment on attachment 182195 [details] Sysinternals Process Monitor output during dead loading period. Did not include gconfd.exe.
This is my third attempt to post the output. Sorry for the delay. It was hard to determine exactly what events were during the dead load period, but I think I got it. I wrote down the event number when it paused for extended periods of time, and then had to hunt for when it picked up again. It went through a very slow progression in the dead load period for about 12 mins, and then quickly finished. I have pre and post if you want them.
Created attachment 182209 [details] Sysinternals Process Monitor output during dead loading period.
Sorry, I forgot to zip it up. After looking at the output, almost all of the big 10sec gaps are preceded by: 1507 2:15:55.7722821 PM gnucash.exe 5184 RegCloseKey HKLM\System\CurrentControlSet\Services\Tcpip\Parameters SUCCESS And immediately followed by: 1508 2:16:05.7725642 PM gnucash.exe 5184 DeviceIoControl \Device\NetWareRedirector BAD NETWORK NAME Control: 0x14018f (Device:0x14 Function:99 Method: 3) NetWare is a Novell network thing. Most of the other 1-2sec gaps are UDP sends and receives on ports 3243-3629 to domains related to my work. I am not sure what all the network communication is for, but they make up almost all of the delays.
(In reply to comment #38) > And immediately followed by: > > 1508 2:16:05.7725642 PM gnucash.exe 5184 DeviceIoControl > \Device\NetWareRedirector BAD NETWORK NAME Control: 0x14018f (Device:0x14 > Function:99 Method: 3) > > NetWare is a Novell network thing. My PC with this issue is also connected to a Novell network.
Christian Stimming stated in comment 25 that John Doppke has this problem. Both Manfred Usselmann and I have this problem. The common detail is that we are all on a Novell networks. New Questions: 1) Is anyone that is having this problem not on a Novell network? 2) Why is GnuCash doing any network communication? 3) What is it about the network communication that conflicts with Novell?
I too am connected to a Novell Network.
Thanks for all the feedback. (In reply to comment #40) > Christian Stimming stated in comment 25 that John Doppke has this problem. > > Both Manfred Usselmann and I have this problem. > > The common detail is that we are all on a Novell networks. > > New Questions: > 1) Is anyone that is having this problem not on a Novell network? > 2) Why is GnuCash doing any network communication? GnuCash itself doesn't contain any code to de network communication. Gconf on the other hand uses a network connection to localhost in some cases. While this is strictly speaking a network connection indeed, it should be an internal network connection and never really leave your PC. If it does, there is something in the underlying system that makes it so. It is already known that Windows has a rather unorthodox way of defining the "localhost" domain name. To work properly, it should resolve to 127.0.0.1 You can easily test what it resolves to on your system by opening a command console and enter ping localhost Do you get any delays as well from that command by the way ? And if the command output indicates that localhost resolves to anything other than 127.0.0.1, can you modify this file: %SystemRoot%\system32\drivers\etc\hosts in such a way that it defines localhost to mean 127.0.0.1 The file should contain some examples to help you set this up. And try to start gnucash again afterwards. > 3) What is it about the network communication that conflicts with Novell? I have no idea. Is there a way you can completely disable your Novel Network and try to start GnuCash then ? Does it still take so long to start ? And one final detail: I noticed from the gconf commands that you are using Dropbox and have stored your data file in you local Dropbox directory. I don't know how dropbox works exactly, so I don't know if this matters. But could you also try to copy your data file to a local directory and open it from there, just to eliminate possible causes ? Thanks.
(In reply to comment #42) > Do you get any delays as well from that command by the way ? > And if the command output indicates that localhost resolves to anything other > than 127.0.0.1, can you modify this file: > %SystemRoot%\system32\drivers\etc\hosts > in such a way that it defines localhost to mean 127.0.0.1 > The file should contain some examples to help you set this up. > And try to start gnucash again afterwards. No delays when pinging localhost: Microsoft Windows XP [Version 5.1.2600] (C) Copyright 1985-2001 Microsoft Corp. C:\>ping localhost Pinging 09TBONGIORNO [127.0.0.1] with 32 bytes of data: Reply from 127.0.0.1: bytes=32 time<1ms TTL=128 Reply from 127.0.0.1: bytes=32 time<1ms TTL=128 Reply from 127.0.0.1: bytes=32 time<1ms TTL=128 Reply from 127.0.0.1: bytes=32 time<1ms TTL=128 Ping statistics for 127.0.0.1: Packets: Sent = 4, Received = 4, Lost = 0 (0% loss), Approximate round trip times in milli-seconds: Minimum = 0ms, Maximum = 0ms, Average = 0ms C:\> > I have no idea. Is there a way you can completely disable your Novel Network > and try to start GnuCash then ? Does it still take so long to start ? Unfortunately, I can not disable it on my work PC which exhibits the problem. I will look into it to double check. > And one final detail: I noticed from the gconf commands that you are using > Dropbox and have stored your data file in you local Dropbox directory. I don't > know how dropbox works exactly, so I don't know if this matters. But could you > also try to copy your data file to a local directory and open it from there, > just to eliminate possible causes ? I experienced the same problem from a local non-dropbox directory. I copied my GnuCash data files to my desktop. I had to open GnuCash, wait 12+ minutes, open the data files on my desktop, quit GnuCash, reopen it, wait 12+ minutes, and verify that it opened the one from my desktop. Hahaha! It is the least I can do to help though! BTW, I use GnuCash at home on my Mac from a local dropbox directory with no problem. Problem is that the best time for me to manage my finances is at work during lunch time!
(In reply to comment #42) > [...] It is already known that > Windows has a rather unorthodox way of defining the "localhost" domain name. > To work properly, it should resolve to 127.0.0.1 > > You can easily test what it resolves to on your system by opening a command > console and enter > ping localhost Pinging CNU6411PMZ [127.0.0.1] with 32 bytes of data: Reply from 127.0.0.1: bytes=32 time<1ms TTL=112 Reply from 127.0.0.1: bytes=32 time<1ms TTL=112 Reply from 127.0.0.1: bytes=32 time<1ms TTL=112 > Do you get any delays as well from that command by the way? No delays. > And if the command output indicates that localhost resolves to anything other > than 127.0.0.1, can you modify this file: > %SystemRoot%\system32\drivers\etc\hosts > in such a way that it defines localhost to mean 127.0.0.1 > The file should contain some examples to help you set this up. > And try to start gnucash again afterwards. This did not help. > > 3) What is it about the network communication that conflicts with Novell? > I have no idea. Is there a way you can completely disable your Novel Network > and try to start GnuCash then ? Does it still take so long to start ? I need the Netware connection to access the company network and better not play around with it. > And one final detail: I noticed from the gconf commands that you are using > Dropbox and have stored your data file in you local Dropbox directory. I don't > know how dropbox works exactly, so I don't know if this matters. But could you > also try to copy your data file to a local directory and open it from there, > just to eliminate possible causes ? I'm not using Dropbox at all.
I tried logging in to my PC in Novell's "Workstation only" mode, but still got the same delay with Novell errors. Novell must still be loading something in this mode. I also looked for a simple enable/disable switch in the Novell Client Properties, but was quickly overwhelmed with all of the settings. I have no idea of what to turn off. As with Manfred Usselmann, this is a work PC and I can't really change the configuration.
Ok, thanks. Don't worry if you can't disable the Novell stuff. We'll have to find another way to get to the core of the issue. The unfortunate part is that I'm steering completely blind here as I don't have access to either Windows 7 or a Novell network. I'm even starting to doubt if it is really gconf that is delayed. When you ran the command line tests, did you experience any delay there ? Perhaps in the order of 10 seconds or there about ? That would suggest it is really gconf being held up for no good reason. If the gconf commands above worked immediately, it might be something else - what is still to be determined. As another approach we could ask gnucash to report much more detail in its trace file. Here is how: * start > run... > cmd.exe * cd "C:\Program Files\GnuCash\bin" * gnucash --debug --log "gnc.gui=debug" This will start gnucash while adding some more detailed information to the trace file. Just let it start up completely and then attach the most recent trace file please. It should give a hint about where the delay occurs in the code. We may need multiple iterations of this to really pinpoint the cause. I hope you have the patience to continue all these tests.
(In reply to comment #46) > I'm even starting to doubt if it is really gconf that is delayed. When you ran > the command line tests, did you experience any delay there ? Perhaps in the > order of 10 seconds or there about ? That would suggest it is really gconf > being held up for no good reason. If the gconf commands above worked > immediately, it might be something else - what is still to be determined. All of the command line tests returned immediately. > As another approach we could ask gnucash to report much more detail in its > trace file. Here is how: > * start > run... > cmd.exe > * cd "C:\Program Files\GnuCash\bin" > * gnucash --debug --log "gnc.gui=debug" > > This will start gnucash while adding some more detailed information to the > trace file. Just let it start up completely and then attach the most recent > trace file please. It should give a hint about where the delay occurs in the > code. We may need multiple iterations of this to really pinpoint the cause. I > hope you have the patience to continue all these tests. Done. See attached trace.
Created attachment 182358 [details] GnuCash trace in response to comment 46.
Grmbl. Now that's a surprise: the windows trace doesn't contain any timestamps while my linux box does generate time stamps. Unfortunately I can't guess at all from your trace file where the time delays happen. I'll try if I can fix this in the code. Until then, I don't see much more we can test to find the root cause of this delay.
There was an obvious pause in the growth of the file while in the dead load period. For the first file, it was about 9K in size. I can easily do it again, save a copy when it pauses, and another when it finishes. You can do a delta to see the difference. Will this help?
Created attachment 182363 [details] GnuCash trace during pause as described in comment 50.
Created attachment 182364 [details] GnuCash trace after loaded as described in comment 50.
Created attachment 182365 [details] GnuCash trace after quiting as described in comment 50.
The delay happened between line 70 and 71. Unfortunately nothing during the dead load period is printed. * DEBUG <gnc.gui> [gnc_gnome_get_gdkpixbuf] Loading pixbuf file C:\Program Files\gnucash\share\gnucash/pixmaps/gnc-invoice-duplicate-16.png * INFO <qof.engine> [guid_init] got 2299 bytes
I had reported this same issue (one which points to Novell networking components). Please see the summary of Bug 551888 and other comments. I can also confirm that this was essentially due to the libgnc making some kind of network enumeration, which was getting stuck while trying to look for netware related resource. Uninstalling Novell Client from my Windows box resolved the problem in my case.
(In reply to comment #55) > I had reported this same issue (one which points to Novell networking > components). Please see the summary of Bug 551888 and other comments. > > I can also confirm that this was essentially due to the libgnc making some kind > of network enumeration, which was getting stuck while trying to look for > netware related resource. > > Uninstalling Novell Client from my Windows box resolved the problem in my case. Thanks for the input. At this point, I think that we have all come to the conclusion that it has something to do with Novell. Identifying that it is libgnc making some kind of network enumeration is great info. Hopefully the devs can work with this to solve the problem in libgnc. Unfortunately, most user with this problem are required to have a Novell client installed for work. Therefore, uninstalling the Novell client is not an option. Hopefully this is not the final solution to this problem.
(In reply to comment #54) > The delay happened between line 70 and 71. Unfortunately nothing during the > dead load period is printed. > > * DEBUG <gnc.gui> [gnc_gnome_get_gdkpixbuf] Loading pixbuf file C:\Program > Files\gnucash\share\gnucash/pixmaps/gnc-invoice-duplicate-16.png > * INFO <qof.engine> [guid_init] got 2299 bytes Hmm, there are several things in the code happening between those two lines. So we will need some more debugging info. I have inserted some additional debug markers in the code to have a better idea where the code hangs. These markers will appear in the nightly build that will be created in a couple of hours [1] Can you install that build (if it didn't fail at least due to today's translation additions). And generate a trace file again ? Note that I haven't checked on the missing time stamp yet, so I'm afraid I'll have to count on you to tell me where the log suspends and resumes. Also please note that you should use a slightly modified command to get the new detailed logs: gnucash --debug --log "gnc.gui=debug" --log "qof.engine=debug" --log "gnc.guile=debug" This should all be on one line, but bugzilla may split it over multiple lines [1] the nightly builds can be found here: http://code.gnucash.org/builds/win32/trunk/
I have attached another trace file (gnucash.trace.L3T7RV.log.zip) from the gnucash-2.4.3-svn-r20367 install. It seems to pause during the dead load period between lines 76 and 77. * DEBUG <qof.engine> [enter ../../../../repos/src/libqof/qof/guid.c:guid_init()] * INFO <qof.engine> [guid_init] got 2299 bytes
Created attachment 182491 [details] GnuCash trace as described in comment 58.
Ok, now it starts making a bit more sense. I was more or less expecting the dead period to happen there, but I needed your confirmation to continue. The guid_init function basically tries to generate as much randomness as possible, so that each object in the GnuCash data file can get a good unique guid. The trouble is, this function does a number of things that are highly linux (or unix) specific. It attempts to read files that I'm pretty sure don't exist on Windows and more of that stuff. This function clearly has to be reviewed for the Windows build of GnuCash. I'm not sure though which of the several steps in there is cause trouble on Windows. So I have added some more debug log lines. I'll ask you one more time to run the next nightly build in the same way as your ran the last one and report where the delay happens now. From there on, I will take it to the drawing board and discuss with the other devs.
Sorry for the delay. The Bongiorno household is quite busy on the weekend. I have attached another trace file (gnucash.trace.LC72RV.log.zip) from the gnucash-2.4.3-svn-r20378 install. It seems to pause during the dead load period between lines 99 and 100. * DEBUG <qof.engine> [enter ../../../../repos/src/libqof/qof/guid.c:init_from_dir()] dirname: \ * DEBUG <qof.engine> [leave init_from_dir()]
Created attachment 182709 [details] GnuCash trace as described in comment 61.
Glad I let you run the test once more. I didn't expect the delay in that particular spot. Neither did I expect dirname to be "\". This should have been a temporary directory. On linux and friends this is typically /tmp. On Windows there are several options, but not "\". Anyway, I have committed a small patch to make sure this is replaced with "c:/temp", one of the valid options for a temporary directory and one I found recommended on the internet when searching for a solution. You may want to try tomorrow's nightly build to see if your delay is gone now. If not, I'll have to ask you again where it delays now.
You got it! There is no more delay! It took 10-15 seconds to load! Is this a final solution? If so, when can we expect it to be in a stable build? I apologize if that type of question is taboo. BTW, I tested with gnucash-2.4.3-svn-r20381 install.
(In reply to comment #64) > You got it! There is no more delay! It took 10-15 seconds to load! Great ! > Is this a final solution? It should be. Debugging this issue turned up some other areas of improvement in the guid code, but my change will be in there until the whole code is overhauled. And even the new code should not regress in this way, because it will use a Windows native function to generate the guid's and no longer depend on the weird randomness generation that is in there now. > If so, when can we expect it to be in a stable build? I > apologize if that type of question is taboo. > Well, you can ask, but I don't know the answer. I guess when there are "sufficient new bugfixes" we will release a new bugfix release. But I don't know what amounts to "sufficient new bugfixes". > BTW, I tested with gnucash-2.4.3-svn-r20381 install. If that version works fine for you, I'd suggest you continue to use it until a new stable (bugfix) release comes out. The current nightly builds are all intended to be stable anyway and only contain bugfixes.
Oh, and thanks once more for running all these time consuming tests. Without them I could never have fixed this.
I can also confirm that this bug is fixed now with the latest nightly build! Super! Many thanks to Geert and Tom!
Thanks and it was my pleasure! It was the least I could do.
GnuCash bug tracking has moved to a new Bugzilla host. This bug has been copied to https://bugs.gnucash.org/show_bug.cgi?id=521817. Please update any external references or bookmarks.