GNOME Bugzilla – Bug 121740
'nextPage != NULL' assertion failure [gnucash 1.8.4 crash in guile with SX]
Last modified: 2018-06-29 20:37:15 UTC
If I have scheduled transactions set up with AutoCreate on and no transactions details itself set up (the debit/credit ledger part at the bottom of the "creating new SX" widget doesnt have any account information) then doing "Since Last Run" on the day of the transaction causes a crash in guile. The backtrace is attached. This is actually an abort when trying to create some widget, I think, from this statement. ---- ** ERROR **: file dialog-sxsincelast.c: line 1604 (sxsincelast_init): assertion failed: (nextPage) aborting... Abort (core dumped) ---- To find this out, I manually gunzip-ed the data file, and edited the XML (shudder!!) piece by piece until I found that putting a 'n' for these two lines fixed the crash: <sx:autoCreate>y</sx:autoCreate> <sx:autoCreateNotify>y</sx:autoCreateNotify> Here is the backtrace in case it helps. Thanks. (gdb) bt
+ Trace 40029
Hmm, can't duplicate this on the CVS. But there is a SX editor bug fix that may have fixed the problem. I'll check later today when I have access to an earlier version. Am I right in thinking that you create a new scheduled transation, but don't fill in anything in the register box at the bottom? No account, no credit, no debit?
OK, I've duplicated this bug. It seems to happen when an invalid SX is created (without account entries), Gnucash is shut down and then restarted. The SX entry in the xac file is incomplete and an exception is raised when trying to create the transaction. I'm inclined to tackle this by preventing the creation of the invalid SX. Looking into it further.
Hi, yes, this is caused by the creation of a SX without any account, credit or debit information. I use SX primarily to remind me when bills are due, and dont use the auto-create/auto-notify functionality; that is why I didnt fill out the full information. I didnt think that the auto-create functionality is the default. Ideally I would prefer it if you do allow the creation of a SX that has no account, debit or credit information if it is not set to auto-create. The account info is only needed when auto-create is there, or if the user wants to click 'create' on the "Since Last Run" dialog. But, more importantly, I definitely dont want it to crash. Display a crash, prevent me from doing something like this, but please dont crash.. My life information exists in gnucash.. :)
I meant to say "display a message", not "display a crash" in my previous comment. Sorry about that.
OK, sounds fine to me. I didn't think of using the SX system as a reminder, but you are right, that is a perfectly valid use, and of course it shouldn't crash (actually, strictly speaking it isn't a crash, its detecting what it thinks is an invalid condition and calling g_assert to force an exit). However, it could certainly be handled a lot more gracefully. I'll have a look at catching it more elegantly. By the way, I'm not the original author of this code, so it takes me a little time to work my way through it. Don't expect a fast fix. May take me a week or so.
*** Bug 132870 has been marked as a duplicate of this bug. ***
*** Bug 116062 has been marked as a duplicate of this bug. ***
*** Bug 115512 has been marked as a duplicate of this bug. ***
*** Bug 120927 has been marked as a duplicate of this bug. ***
Adding y'all from the various duplicates to be CC's on this bug. This is the bug to track regarding the "nextPage assertion failure" crash. Nigel, if you don't mind, I'm going to take assignment of this bug, as I'm actively working on it.
Go ahead Josh. I'm back at work, which is why I've slowed down on this one.
This will happen in two ways: 1/ As described above, if there is no template transaction to actually 'be created. 2/ If there is an error in the parsing of the credit/debit formula for the template transaction, perhaps caused by an inappropriate LANG setting leading to a parsing error [e.g., because of a "," decimal seperator in the credit/debit formula used with an english/us locale]. In the first case, I don't know quite what to do, except more strongly assert during creation time that any "auto-create" SX _must_ have a valid template transaction. I believe this was true, but apparently not. [As a bit of a side note: the "auto-create" feature is _very_specifically_ for SXes with a template transaction ... if there's no template transaction, what is there to auto-create? If/when you are using SXes as a reminder, you will likely want to de-select the "auto-create" option.] In the second case, gnucash shouldn't abort quite as suddenly, but instead close the since-last-run dialog with an error message.
Changed title to be more descriptive. Prevention of the second scenario is done [not yet in CVS]. The first case is also handled much better, now [not yet in CVS] -- see Bug#120311].
Mostly fixed in 2004.03.08 commit on 1.8-branch and HEAD. The user is now prevented from selecting auto-creat on SXes which have no template transaction. With respect to the decimal seperator issue, use the LC_MONETARY envrionment variable to control that handling apart from the language setting. As well, if there is an error in creating the transaction, the SX will be skipped rather than screwing up gnucash.
GnuCash bug tracking has moved to a new Bugzilla host. This bug has been copied to https://bugs.gnucash.org/show_bug.cgi?id=121740. Please update any external references or bookmarks.