The first-line cause of the bug was that the safe save was failing on
SQLite3 because the backup tables weren't visible inside the
transaction and that prevented them from being dropped. Commit the
transaction before trying to drop the backup tables.
https://bugs.gnucash.org/show_bug.cgi?id=799623 identified a problem
with int64_t storage in SQLite3 by setting a date after 2038-01-23
whose time64 overflowed int32_t. But dates shouldn't be stored as
time64s, they should be stored as ISO 8601 date-time strings. So fix
the test to store the date correctly and to store the big int as an
int64_t.
clear lock on the origin SQL book.
GncDbiSqlConnection::unlock_database function errored out if the last
dbi interaction resulted in an error, even if it was a harmless index
out of range. Ignore index out of range errors.
Not quite true, it just takes a really long time for a large database.
The underlying problem is gnc_file_do_save_as reloads the data to make
sure that the save-as saves everything. On the SQL backend that
triggers a scrub. The scrub itseld doesn't take long, but every
transaction commit was logged in the transaction log and did a refresh
of the registers. So:
* Suspend logging while doing the scrub.
* Suspend UI refreshes and QOF events while reloading the data.
Scrubbing during SQL load can't commit the changes from the scrub
because the backend's m_loading member is true so disable scrubbing
during database load and edit/commit all transactions again after
loading is complete.
To use pass -DCMAKE_BUILD_TYPE=Debug or Asan -DCOVERAGE=ON and build as
usual, then do ninja lcov-initialize && ninja check && ninja
lcov-collect. The result will be a directory, <Builddir>/Coverage
containing lcov tracefiles, including an aggregate file gnucash.info
which you can use for further processing. It will also report an overall summary.
Note that only C/C++ files are included.
There's one more target, lcov-generate-html, that you can run after
lcov-collect. It will generate a simple website in
<Builddir>/Coverage-HTML showing coverage by source directory (the
directories in <Builddir> have coverage for generated files). Each
directory path is a clickable link to a page that shows coverage for
each source file; the filenames link to a page for each showing which
lines have been exercised.
Every test was rebuilding it except for gnc-backend-xml.cpp from
scratch, no point in that plus the Address Sanitizer needs the
definition of GncBackendXml.
xaccSplitComputeCapGains creates gains_split pointers in both the Cap Gains Split and its Income split to the original split, but the original's gains_split pointer can point to only one of them, the Cap Gains split. When the original split is freed both the Cap Gains split's and its Income split need their gains_split pointers NULLed or when it's the Income split's turn to be freed it will try to deref the dangling pointer.
For wrong value type when retrieving a value from the SQL results row.
Profiling showed that most of the SQL load time was spent in handling
these exceptions, and using std::optional instead produced a > 11x
speedup (10 seconds vs. 115 seconds) when loading a large file.
Add new test files that are written with the latest version of GnuCash.
Test loading them, saving to compressed files, loading those compressed
files and writing to an uncompressed file. At every stage check it matches
the canonical version.
Valgrind uses "still reachable" because of the call to exit()
==87185== 94 bytes in 1 blocks are still reachable in loss record 193 of 241
==87185== at 0x4843828: malloc (in /usr/libexec/valgrind/vgpreload_memcheck-amd64-linux.so)
==87185== by 0x15C234: main (test-xml2-is-file.cpp:42)
==87185==
==68902== 8 bytes in 1 blocks are definitely lost in loss record 7 of 251
==68902== at 0x4843828: malloc (in /usr/libexec/valgrind/vgpreload_memcheck-amd64-linux.so)
==68902== by 0x5225948: g_malloc (in /usr/lib/x86_64-linux-gnu/libglib-2.0.so.0.7600.1)
==68902== by 0x5240ED2: g_strdup (in /usr/lib/x86_64-linux-gnu/libglib-2.0.so.0.7600.1)
==68902== by 0x13135E: g_strdup_inline (gstrfuncs.h:321)
==68902== by 0x13135E: dom_tree_to_text(_xmlNode*) (sixtp-dom-parsers.cpp:500)
==68902== by 0x141758: test_bad_string() (test-string-converters.cpp:70)
==68902== by 0x1417D8: main (test-string-converters.cpp:82)
==68902==
==68902== 93 bytes in 5 blocks are definitely lost in loss record 199 of 251
==68902== at 0x4843828: malloc (in /usr/libexec/valgrind/vgpreload_memcheck-amd64-linux.so)
==68902== by 0x5225948: g_malloc (in /usr/lib/x86_64-linux-gnu/libglib-2.0.so.0.7600.1)
==68902== by 0x5240ED2: g_strdup (in /usr/lib/x86_64-linux-gnu/libglib-2.0.so.0.7600.1)
==68902== by 0x13135E: g_strdup_inline (gstrfuncs.h:321)
==68902== by 0x13135E: dom_tree_to_text(_xmlNode*) (sixtp-dom-parsers.cpp:500)
==68902== by 0x14169B: test_string_converters() (test-string-converters.cpp:55)
==68902== by 0x1417D3: main (test-string-converters.cpp:81)
==68902==
==68902== 260 (120 direct, 140 indirect) bytes in 1 blocks are definitely lost in loss record 242 of 251
==68902== at 0x4843828: malloc (in /usr/libexec/valgrind/vgpreload_memcheck-amd64-linux.so)
==68902== by 0x48D5B84: xmlNewNode (in /usr/lib/x86_64-linux-gnu/libxml2.so.2.9.14)
==68902== by 0x133873: text_to_dom_tree(char const*, char const*) (sixtp-dom-generators.cpp:53)
==68902== by 0x141748: test_bad_string() (test-string-converters.cpp:68)
==68902== by 0x1417D8: main (test-string-converters.cpp:82)
==68902==
==68902== 1,353 (600 direct, 753 indirect) bytes in 5 blocks are definitely lost in loss record 248 of 251
==68902== at 0x4843828: malloc (in /usr/libexec/valgrind/vgpreload_memcheck-amd64-linux.so)
==68902== by 0x48D5B84: xmlNewNode (in /usr/lib/x86_64-linux-gnu/libxml2.so.2.9.14)
==68902== by 0x133873: text_to_dom_tree(char const*, char const*) (sixtp-dom-generators.cpp:53)
==68902== by 0x14168B: test_string_converters() (test-string-converters.cpp:54)
==68902== by 0x1417D3: main (test-string-converters.cpp:81)
==68902==
g_assert() can be compiled out, so should not be used for tests
g_assert_true was removed
to fis https://bugs.gnucash.org/show_bug.cgi?id=792008 because
g_assert_true was introduced in glib-2.38 and at the time GnuCash required
only glib-2.26. GnuCash has required glib >= 2.40 since 8acbc41c6 so
g_assert_true can be restored.
Return a gnc_numeric instead of allocations that every caller has to free.
This makes it easier to fix the use after free in the unit test function
equals_node_val_vs_split_internal() where the expression in the return
statement wants to use the allocated gnc_numeric.
Christopher Lam
John Ralls
Bill Sommerfeld
peter15914
David Seifert
Kanstantin K.
Geert Janssens
Simon Arlott
Richard Cohen
Vincent Dawans