... when called from guile e.g. test-transaction and lots of other tests
- gchar will also get the char* typemap, by typedef reduction
==119964== Mismatched free() / delete / delete []
==119964== at 0x4847A1F: operator delete[](void*) (in /usr/libexec/valgrind/vgpreload_memcheck-amd64-linux.so)
==119964== by 0x669F3E4: _wrap_gnc_print_time64(scm_unused_struct*, scm_unused_struct*) (swig-engine.cpp:38533)
...
==119948== Mismatched free() / delete / delete []
==119948== at 0x4847A1F: operator delete[](void*) (in /usr/libexec/valgrind/vgpreload_memcheck-amd64-linux.so)
==119948== by 0x6F6B431: _wrap_qof_print_date(scm_unused_struct*) (swig-engine.cpp:39124)
...
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)
When loading the book on startup, GnuCash takes a long time. This is partly
because gnc_restore_all_state() is loading data for every register page and
I have 35+ registers open.
Register loads should be deferred on tabs that are not visible until those
tabs are focused, like what already happens for restored open reports.
Every time a change to a transaction is saved by navigating away from it,
the UI freezes for almost a second. This is because
gnc_split_register_move_cursor() calls gnc_gui_refresh_internal() which
refreshes all the registers.
Register refreshes should be deferred on tabs that are not visible until
those tabs are focused again.
Use focus information to suppress the last part of the refresh_handler()
if the ledger isn't currently visible. When it becomes visible again, run
the deferred refresh step.
Don't immediately load or refresh the ledger (this will happen the first
time it is focused instead).
This has to disregard the "open adjacent" preference to get them to be in
the right order because the first page will remain focused until the
restore is complete.
Change the register page so that it doesn't assume it will be in focus on
creation.
gnc_ledger_display_gl() is called to create the ledger:
1. Exclude template accounts (unconditionally)
2. Calls gnc_ledger_display_internal()
gnc_ledger_display_internal():
1. Run query
2. Set watches
3. Load splits
refresh_handler() is called to refresh all pages when a change happens:
1. Check if the number of subaccounts has changed
2. Exclude any template accounts (for specific register types)
3. Run query
4. Set watches
5. Load splits
gnc_ledger_display_refresh() is called by the register plugin:
1. [Doesn't check if the number of subaccounts has changed]
2. Exclude template accounts (for specific register types)
3. Run query
4. Set watches
5. Load splits
The last two are inconsistent because they don't both check if the number
of subaccounts has changed.
Make it easier to conditionally refresh the ledger only when it's visible
by consolidating the code from these functions into one place within
gnc_ledger_display_refresh() and gnc_ledger_display_refresh_internal().
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.
