[GNC-dev] Windows build fails to run
14ubobit at gmail.com
Tue May 12 07:28:34 EDT 2020
So the logging is different now, updated master on my Linux VM and with
nothing else changed in that environment which has been building with -ggdb.
Built OK but when I ran it I ended up with an unresponsive Gnucash, ended
up by force quitting. Looked at the trace file which was 1.6GB.
Looking at it, it looks like it is every single INFO, DEBUG message
Previously, to get more trace information I would start gnucash with
--debug and then control the module detail I wanted with a log.conf file.
Do I need to do something different now, always use a log.conf with every
entry set to info and then set individual modules to debug when required.
I have not tried this yet but will later to see how much is logged.
On Mon, 11 May 2020 at 17:28, John Ralls <jralls at ceridwen.us> wrote:
> > On May 11, 2020, at 4:45 AM, Robert Fewell <14ubobit at gmail.com> wrote:
> > #6 0x0244ae57 in qof_log_check (domain=0x0, level=(QOF_LOG_WARNING |
> unknown: 2))
> > at
> That's what I suspected. I made qof_log_check do a g_return_value_if_fail
> on domain=NULL and it caused crashes in some tests that didn't have
> G_LOG_DOMAIN set.
> > Have you noticed that the Windows trace file has DEBUG entries as
> Yeah, that's on purpose because for most users getting a stack trace is
> too hard. Having GnuCash always run with --debug gets as much info on
> crashes as possible. What I'm not sure about is how G_DEBUG is getting set.
> Unless something got changed in GLib recently that's what turns on
> g_abort() from a CRITICAL log message.
> So I'll rework qof_log_check to log a WARNING about a NULL domain and use
> a substitute one (maybe "gnc.unknown") for the log message.
> John Ralls
More information about the gnucash-devel