question about warning on stderr

[incoming-gnucash at sabot.com]

   To: incoming-gnucash at sabot.com
   From: John Ralls <jralls at ceridwen.us>
   Date: Mon, 12 May 2014 07:06:50 -0700
   Subject: Re: question about warning on stderr
   
   
   On May 10, 2014, at 7:10 PM, incoming-gnucash at sabot.com wrote:
   
   > 
   > Now that I'm paying attention to seemingly innocuous things coming out
   > of gnucash such as console warnings, I do have two followup questions
   > on stuff I see in tmp.  The easy one first: I noticed that my tmp
   > directory has a copy of an html file for each report I view, names
   > like "gnc-report-abcdef.html".  They do not seem to get deleted
   > automatically by gnucash when I close the report tab or even when I
   > exit gnucash.  Is that how it is supposed to work; it relies on me
   > rebooting my machine (or some /tmp cleaning cron job) to sweep things
   > away eventually, or maybe gnucash deletes if older than 30 days?  Is
   > there a way to ask gnucash to put the files in some directory that I
   > specify instead of /tmp?
   > 
   > Second, I noticed that gnucash generates a gnucash.trace file in /tmp.
   > Although gnucash ran fine for me today, the trace file it left behind
   > has various warnings, some with "CRIT" on them.  For example, I see
   > many like this:
   > 
   >  * 08:36:15  CRIT <GLib> g_date_compare: assertion `g_date_valid (lhs)' failed
   > 
   > others like these:
   >  * 08:32:56  CRIT <gnc.gui> Object 0x26ce6a0 is already in list of GncPluginPageSxList
   >  * 08:38:10  CRIT <GLib> g_hash_table_lookup_extended: assertion `hash_table != NULL' failed
   >  * 08:38:10  CRIT <GLib> g_hash_table_foreach: assertion `hash_table != NULL' failed
   > 
   > And a bunch of aqbanking related warnings (though my import did not
   > report any errors at the gui other than possibly that there were no
   > transactions to download today):
   > 
   >  * 08:46:11  CRIT <gwenhywfar> gui.c: 1605: Progress by id 00000002 not found
   >  * 08:46:11  WARN <aqbanking> g_sonrs.c:   80: Ignoring element [ORIGIN.ID]
   >  * 08:46:11  WARN <aqbanking> g_sonrs.c:   80: Ignoring element [CUSTOMER.TYPE]
   >  * 08:46:11  WARN <aqbanking> g_sonrs.c:   80: Ignoring element [START.TIME]
   >  * 08:46:11  WARN <aqbanking> g_stmtrs.c:  117: Ignoring group [CYCLECUT.INDICATOR]
   >  * 08:46:11  CRIT <aqofxconnect> provider.c:  866: Error importing server response (-57)
   >  * 08:46:16  WARN <gnc.import.aqbanking> bal_accountinfo_cb: noted_bal == NULL.  Assuming 0
   >  * 08:46:45  CRIT <gwenhywfar> gui.c: 1605: Progress by id 00000002 not found
   > 
   > So sort of like my original question: are those CRIT and WARN messages
   > indicating a problem, or should I be ignoring those too?  I know, I
   > probably should not be digging into a trace file if the program seems
   > to be running fine.  My excuse: having just switched over from
   > quicken, I think I'm just very pleased to be using something that
   > isn't a complete black box and where I can look under the hood a bit!
   
   Yes, GnuCash uses the traditional Unix approach that the system is responsible for periodically cleaning out /tmp.
   
   Nearly all of the CRIT warnings from GLib and Gtk are the result of invariant checks, G_RETURN_IF_FAIL() or G_RETURN_VALUE_IF_FAIL(). For example, the g_date_compare error might happen if you try to save a transaction without having entered the date. As long as the default return value is handled correctly in the calling code, there's no harm.
   
   The aqbanking errors look like standard debugging output that normally occurs when dealing with input from an unknown and perhaps not fully standard-compliant source.
   
   In either case, the messages are useful to us when things go wrong; they sometimes help to figure out the source of a problem without the user having to create a stack trace, which is difficult on Windows.
   
   Regards,
   John Ralls
   
That all makes sense to me, thanks.  FWIW, I ran tail -f today on the
trace file while clicking in gnucash to see if I could pin down the
cause and I see that this warning:

* 13:46:14  CRIT <GLib> g_date_compare: assertion `g_date_valid (lhs)' failed
   
can be caused when I edit a scheduled transaction's template and save
it out, likely because it has "Scheduled" in the date field.  The
warning came out when I clicked that I was done with it, just before
the gui asked "The curent template transaction has been changed. Would
you like to record the changes?".

Am I right that it is correct to have that non-date format word
"Scheduled" in the date field in a scheduled transaction template?  If
so, the invariant check is a bit overzealous for this caller, but of
course no harm is caused by having the warning.

--gary