When selecting Save As to an existing file, an Overwrite (Y/N) dialog box pops up, but is in the background and covered by Save As dialog box. Application appears to be locked as the Overwrite box is not visible. Unable to ALT+TAB to select the background dialog box. Only solution currently is to move the Save As dialog before selecting the file to overwrite OR to minimize all windows and then select GnuCash application from task bar, at which time the Overwrite dialog box moves to foreground.
I have looked into this and the cancel dialog did not have a transient parent, this can be fixed on gnc-file.c lines 1474 and 1237. This adds a transient parent but the wrong one, it should be the "Save As" dialog. This can be changed in dialog-file-access.c line 153 and probably 149 and 157. While proving this to create a PR I was getting a segfault when selecting cancel so ran it from GDB with the backtraces added as an attachment. Not sure what is wrong as it dives into cpp files.
Created attachment 372943 [details] Backtraces The first one concerning engine.sx I was getting sometimes but the following one I think is the main cause in two formats
The first one is about having an SX in your book that points to a non-existent account. Normally it would just write that to the tracefile, but it aborts in the debugger because it's a critical error. The second one seems to be because the GncXmlSession's m_book has gotten corrupted. Either it was set to a bad value at load or your compiler isn't creating a correct default constructor. load is more likely, so break on GncXmlBackend::load and see what's getting passed in. If it's a valid book then set a watch on GncXmlBackend::m_book and see if it's getting changed somewhere.
Still trying to figure this out but what I have found it is not just my build. I rebooted my PC into windows 10, downloaded the latest nightly and open a xml data file, tried to "Save As", selected another existing xml data file, the dialog comes up to ask to over write, used the 'Cancel' button and hey presto it would crash. On some occasions it would work, looking at the trace file below, the first two worked, last one crashed. * 11:28:34 WARN <gnc.backend> [GncXmlBackend::session_begin()] Might clobber, no force * 11:28:36 CRIT <gnc.engine.sx> gnc_sx_get_sxes_referencing_account: assertion 'sxactions != NULL' failed * 11:29:14 WARN <gnc.backend> [GncXmlBackend::session_begin()] Might clobber, no force * 11:29:15 CRIT <gnc.engine.sx> gnc_sx_get_sxes_referencing_account: assertion 'sxactions != NULL' failed * 11:29:28 WARN <gnc.backend> [GncXmlBackend::session_begin()] Might clobber, no force Can not get the watch to work, I break on load, step until m_book set and then use 'watch GncXmlBackend::m_book' but that doesn't last. Tried 'p m_book' which gives correct value, got the address with 'p &m_book' and then tried 'watch *0x7fffd0002ac0' but does not fire, maybe it's because I am using VirtualBox VM?
Bob, I tried to replicate your crash and couldn't. As you suggested in comment 1 I replaced the call to gnc_ui_get_main_window(GTK_WIDGET(dialog)) with GTK_WINDOW(dialog) at the specified lines. That fixes the "overwrite" dialog disappearing behind the filechooser dialog so one can tell it "No" (*not* "Cancel"). I did that five times in a row with no crash. I do see the "sxactions != NULL" assertion message, so that's a completely separate issue.
John, After adding some cout statements I can fix my crash in two ways. Firstly by adding this... m_book = qof_session_get_book (session); to GncXmlBackend::session_begin after the m_fullpath statement or by moving this... m_book = book; in GncXmlBackend::load to before the if(loadType... statement. Not sure if either is valid but you will know.
Created attachment 372944 [details] File of cout statements This may not be of any use but this was the output I was getting when trying to monitor m_book.
OK I spoke to soon, the only reliable way for me is the first change. I think I will create a PR to fix what this bug is for and ponder, may be it is my system but can not explain why booting into windows using the latest nightly I can get the same crash failure.
(In reply to Bob from comment #7) > Created attachment 372944 [details] > File of cout statements > > This may not be of any use but this was the output I was getting when trying > to monitor m_book. Hmm. No bad pointers anywhere: Either a legitimate value or a nullptr.
I'm baffled that setting m_book = qof_session_get_book (session) temporarily in GncXmlBackend::session_begin() would prevent m_book pointing into space in session_end(): the last line of session_begin is `m_book = nullptr`.
Created PR 395 to fix what was reported on this bug. If accepted I think this can be closed as the other problem seems to related to my setup.
FWIW I can reproduce the crash on my Fedora 27 system. I have spent some time debugging this and I think Bob's suggestion is definitely pointing in the right direction (good hunting!) The gist of this issue is that GncXmlBackend::m_book = QofSessionImpl::m_book. In the current program flow QofSessionImpl::m_book gets set in the call to qof_session_new at gnc-file.c:1456. That call triggers a QofSessionImpl constructor which creates a new book. GncXmlBackend::m_book only gets set much later, namely in the call to qof_session_swap_data at gnc-file.c:1538. However if save as is cancelled due to some error the code will call qof_session_destroy, before the swap occurs. So at that point GncXmlBackend::m_book is not set yet while at some point in in the session destruction GncXmlBackend::session_end is called which will try to access its m_book. I'm a bit surprised GncXmlBackend's default constructor doesn't initialize m_book to a nullptr though. Perhaps this is safety measure of Fedora's default compiler options ? That also explains why Bob's first line does fix it. It guarantees we have a valid m_book early on. However we don't need a valid book as it will never be used anyway. If save as can continue successfully the book will be swapped with the book of the current session. So to fix, I have simply forced GncXmlBackend::m_book to nullptr on instantiation which seems to fix the crash as well.
Bob's patch for this bug has been merged and will appear in gnucash 3.3. Windows users can already play with it starting with tomorrow's nightly build.
> I'm a bit surprised GncXmlBackend's default constructor doesn't initialize m_book to a nullptr though. Me too, I thought that C++11 had done The Right Thing™ and made default constructors zero out pointers. Apparently not. default-initializing the pointer in the class declaration is the right answer, and I've made a note to go through all of the other class declarations and make sure that all pointers have that.
