John, 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 possible.
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. Regards, Bob On Mon, 11 May 2020 at 17:28, John Ralls <jra...@ceridwen.us> wrote: > > > > On May 11, 2020, at 4:45 AM, Robert Fewell <14ubo...@gmail.com> wrote: > > > > #6 0x0244ae57 in qof_log_check (domain=0x0, level=(QOF_LOG_WARNING | > unknown: 2)) > > at > C:/gcdev64/gnucash/master/src/gnucash-git/libgnucash/engine/qoflog.cpp:308 > > 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 > default? > > > > 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. > > Regards, > John Ralls > > _______________________________________________ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel
