The pointer passed to the gfec exception handler is
not valid after the exception handler ends
==382525== Invalid read of size 1
==382525== at 0x484B050: memcpy@GLIBC_2.2.5 (in /usr/libexec/valgrind/vgpreload_memcheck-amd64-linux.so)
==382525== by 0x531AB67: __printf_buffer_write (Xprintf_buffer_write.c:39)
==382525== by 0x5322CD4: __printf_buffer (vfprintf-process-arg.c:501)
==382525== by 0x53465F3: __vasprintf_internal (vasprintf.c:102)
==382525== by 0x499C8C1: g_vasprintf (in /usr/lib/x86_64-linux-gnu/libglib-2.0.so.0.7600.1)
==382525== by 0x4969BE0: g_strdup_vprintf (in /usr/lib/x86_64-linux-gnu/libglib-2.0.so.0.7600.1)
==382525== by 0x494B2F6: g_logv (in /usr/lib/x86_64-linux-gnu/libglib-2.0.so.0.7600.1)
==382525== by 0x494B7A2: g_log (in /usr/lib/x86_64-linux-gnu/libglib-2.0.so.0.7600.1)
==382525== by 0x4862862: func_op (gnc-exp-parser.c:342)
==382525== by 0x485D381: primary_exp (expression_parser.c:1222)
==382525== by 0x485CE0F: multiply_divide_op (expression_parser.c:1028)
==382525== by 0x485CC33: add_sub_op (expression_parser.c:968)
==382525== Address 0xad387ec is 764 bytes inside a block of size 766 free'd
==382525== at 0x484620F: free (in /usr/libexec/valgrind/vgpreload_memcheck-amd64-linux.so)
==382525== by 0x4861D9B: gfec_apply (gfec.c:145)
==382525== by 0x4862813: func_op (gnc-exp-parser.c:339)
==382525== by 0x485D381: primary_exp (expression_parser.c:1222)
==382525== by 0x485CE0F: multiply_divide_op (expression_parser.c:1028)
==382525== by 0x485CC33: add_sub_op (expression_parser.c:968)
==382525== by 0x485C9DE: assignment_op (expression_parser.c:886)
==382525== by 0x485C101: parse_string (expression_parser.c:605)
==382525== by 0x4862F07: gnc_exp_parser_parse_separate_vars (gnc-exp-parser.c:535)
==382525== by 0x4862D60: gnc_exp_parser_parse (gnc-exp-parser.c:475)
==382525== by 0x10A963: run_parser_test (test-exp-parser.c:94)
==382525== by 0x10AB99: run_parser_tests (test-exp-parser.c:144)
==382525== Block was alloc'd at
==382525== at 0x4843738: malloc (in /usr/libexec/valgrind/vgpreload_memcheck-amd64-linux.so)
==382525== by 0x4A81473: scm_realloc (in /usr/lib/x86_64-linux-gnu/libguile-3.0.so.1.5.0)
==382525== by 0x4AEEF70: scm_to_utf8_stringn (in /usr/lib/x86_64-linux-gnu/libguile-3.0.so.1.5.0)
==382525== by 0x55AA71F: gnc_scm_to_utf8_string (gnc-guile-utils.c:42)
==382525== by 0x4861D4E: gfec_apply (gfec.c:136)
==382525== by 0x4862813: func_op (gnc-exp-parser.c:339)
==382525== by 0x485D381: primary_exp (expression_parser.c:1222)
==382525== by 0x485CE0F: multiply_divide_op (expression_parser.c:1028)
==382525== by 0x485CC33: add_sub_op (expression_parser.c:968)
==382525== by 0x485C9DE: assignment_op (expression_parser.c:886)
==382525== by 0x485C101: parse_string (expression_parser.c:605)
==382525== by 0x4862F07: gnc_exp_parser_parse_separate_vars (gnc-exp-parser.c:535)
Make counters explicitly integer type and adjust the kvp load and save functions
to recognize that and behave accordingly so that other range options like day
threshold aren't affected.
- Also, remove unnecessary "static" in gnucash-style.c
The second one in guid.cpp is UB:
libgnucash/engine/guid.cpp:137:5: warning: undefined behavior, source object type 'const gnc::GUID' is not TriviallyCopyable [bugprone-undefined-memory-manipulation]
memcpy (&target, &source, sizeof (GncGUID));
^
A TXN_TYPE_PAYMENT will have non-APAR splits; a TXN_TYPE_LINK will not
have non-APAR splits. This bug manifests as a regular TXN_TYPE_PAYMENT
transaction being later voided being incorrectly changed to
TXN_TYPE_LINK.
The scrubbing routines are transaction oriented. Instead of
xaccAccountTreeScrubImbalance calling xaccAccountScrubImbalance for
each descendant, refactor so that the transaction list is generated
only once. The scrubbing is faster and progress bar is more accurate.
Bug 798930 caused some counters to be saved as KVP double. If the
correct int64_t value isn't found when reading, or if a double is
encountered when loading the option dialog, get the double value
and cast it to int64_t.
It was failing to produce a correct representation for input with more than
14 digits after the decimal poin. Fixes Bug 798916. The bug was in
powten so this fix may corect other problems too. For example conversion
of GncNumeric back to a string also failed in certain circumsances.
==515314== Invalid read of size 1
==515314== at 0x484AD67: __strcmp_sse42 (in /usr/libexec/valgrind/vgpreload_memcheck-amd64-linux.so)
==515314== by 0x171D36: do_test_list_handler (unittest-support.c:181)
==515314== by 0x171DCE: test_list_handler (unittest-support.c:197)
==515314== by 0x51BD4C1: g_logv (in /usr/lib/x86_64-linux-gnu/libglib-2.0.so.0.7600.1)
==515314== by 0x51BD7A2: g_log (in /usr/lib/x86_64-linux-gnu/libglib-2.0.so.0.7600.1)
==515314== by 0x4D5D0D9: xaccSplitEqualCheckBal (Split.c:753)
==515314== by 0x4D5D841: xaccSplitEqual (Split.c:869)
==515314== by 0x4D647A5: xaccTransEqual (Transaction.c:981)
==515314== by 0x15C0E8: test_xaccTransEqual(Fixture*, void const*) (utest-Transaction.cpp:901)
...
==515314== Address 0x8725260 is 0 bytes inside a block of size 59 free'd
==515314== at 0x484620F: free (in /usr/libexec/valgrind/vgpreload_memcheck-amd64-linux.so)
==515314== by 0x15BDB1: test_xaccTransEqual(Fixture*, void const*) (utest-Transaction.cpp:883)
...
==515314== Block was alloc'd at
==515314== at 0x4843828: malloc (in /usr/libexec/valgrind/vgpreload_memcheck-amd64-linux.so)
==515314== by 0x5618677: __vasprintf_internal (vasprintf.c:116)
==515314== by 0x520E8C1: g_vasprintf (in /usr/lib/x86_64-linux-gnu/libglib-2.0.so.0.7600.1)
==515314== by 0x51DBBE0: g_strdup_vprintf (in /usr/lib/x86_64-linux-gnu/libglib-2.0.so.0.7600.1)
==515314== by 0x51DBC9C: g_strdup_printf (in /usr/lib/x86_64-linux-gnu/libglib-2.0.so.0.7600.1)
==515314== by 0x15BBAC: test_xaccTransEqual(Fixture*, void const*) (utest-Transaction.cpp:879)
...
ok 78 /engine/Transaction/xaccTransEqual
Thanks, Valgrind:
==515314== Invalid read of size 8
==515314== at 0x4ED46F3: gncInvoiceRemoveEntries (gncInvoice.c:767)
==515314== by 0x142B35: teardown_with_invoice (utest-Invoice.c:274)
...
==515314== Address 0x8557b98 is 8 bytes inside a block of size 24 free'd
==515314== at 0x484620F: free (in /usr/libexec/valgrind/vgpreload_memcheck-amd64-linux.so)
==515314== by 0x51B565D: g_list_remove (in /usr/lib/x86_64-linux-gnu/libglib-2.0.so.0.7600.1)
==515314== by 0x4ED42EF: gncInvoiceRemoveEntry (gncInvoice.c:688)
==515314== by 0x4ED46A2: gncInvoiceRemoveEntries (gncInvoice.c:781)
==515314== by 0x142B35: teardown_with_invoice (utest-Invoice.c:274)
...
==515314== Block was alloc'd at
==515314== at 0x4843828: malloc (in /usr/libexec/valgrind/vgpreload_memcheck-amd64-linux.so)
==515314== by 0x51BD948: g_malloc (in /usr/lib/x86_64-linux-gnu/libglib-2.0.so.0.7600.1)
==515314== by 0x51B1CB9: ??? (in /usr/lib/x86_64-linux-gnu/libglib-2.0.so.0.7600.1)
==515314== by 0x4ED4271: gncInvoiceAddEntry (gncInvoice.c:676)
==515314== by 0x142401: setup_with_invoice (utest-Invoice.c:142)
...
ok 57 /engine/gncInvoice/post trans - vendor bill
The test relies on a lot of external dependencies
- installed finance-quote-wrapper
- alpha vantage key
- network
- working remote server
Running ./bin/test-gnc-quotes from the command line
will still include online_wiggle
Pass a boost::filesystem's c_str() rv to the ofstream constructor to
keep libstdc++ from transcoding it back to UTF8 and creating a broken
name or failing to match the directory name. Implemented in
gnc-filepath-utils to avoid spreading the boost::filesystem dependency
throughout the code base.
See https://github.com/boostorg/filesystem/issues/181 for why other
approaches don't work.
When the commodity table is registered, the current book will get
a default table assigned. When later setting the table explicitly
using qof_book_set_data() the exisiting table gets overwritten and
is thus leaked.
There is no way of removing or freeing a currency table from a book,
so the best we can do here is to set our own table on the book before
calling gnc_commodity_table_register().
If a function that returns an allocated pointer is passed directly into
something that does not take ownership of the pointer, the allocation is
leaked. This can be fixed by assigning the pointer to a new variable
and freeing it after operation on the memory.
At least one user has managed to get it set on their book so even
though it was supposed to be unimplemented it got through somehow.
Restoring it allows books with it set to load.
- Renamed option to "Account Balance" to avoid confusion with running
total.
- Added helper function to ensure running balance and balance forward
are only shown when transaction are grouped by account and sorted as
in register. In that case column heading remains "Running Balance"
and balance forward is shown. Otherwwise column heading is renamed
"Account Balance" and balance forward is not shown.
- Also added missing code for Common Currency conversion.
Ensure that dialog resources stored in options are freed when the
dialog is destroyed.
The crash happened when a new dialog replaced the old one on the options
and the old one's destructors tried to access a dangling reference to
a GtkWidget.
Edit/Report Options
As a result of auto instead of auto& in a std::visit call which
resulted in a temporary option whose GncOwner* was destroyed before
we could use it.
The previous change of the delimiter between namespace and symbol
is needed in both overloads of GncQuoteImpl::query_fq.
Also log the query json string to ease future troubleshooting.
This fixes memory leaks that are only present in testing code.
Not very useful on itself, but it does make it easier to fix memory
leaks and other AddressSanitizer problems in actual gnucash code later.
These were not used outside a test.
And that test was not leak free, as a result of the functions not doing
what they are supposed to do when the current value is not of the type
that is expected. (NULL is returned, but the value is not replaced)
Boost process wchar_t conversion chokes if it's fed an empty string.
This would happen when the user had no alphavantage key. Separate
the process invocation to not present the empty value to boost process.
When securities are in the list, the rows look twice as high as though
there is a linefeed at the end. This is partly due to commit for bug
797501 which worked at the time but a change in pango 50.4 to do with
wrapping has highlighted this bug.
To fix this only wrap currencies with ltr bidi isolate characters in
gnc_print_amount_with_bidi_ltr_isolate