Hi John, Sherlock
I installed the nightly build and tested with 3 payments consecutively
and received no errors. It's not exhaustive testing but it does look as
though the problem is resolved. Many thanks for the assistance.
kind regards
James
On 2025/10/14 17:56, John Ralls wrote:
In which case you can try today’s nightly build,
https://code.gnucash.org/builds/flatpak/stable/gnucash-stable-C5.13-9-ge22c406547-D5.13-1-g285f67b7.flatpakref.
Regards,
John Ralls
On Oct 14, 2025, at 08:51, Sherlock <[email protected]> wrote:
Hi James,
Based on the call stack, I suspect this issue was resolved on October
13
byhttps://github.com/Gnucash/gnucash/commit/fb6e8d927ef74921fd68e3f935a4375030fe97d5
Regards,
Sherlock
On 10/14/25 12:11 AM, James Thorpe wrote:
Sure:
running with gdb. I assign as payment, select invoice, get the
"Process Payment" dialog. Select cusomer, invoiceand then as soon as
I click "OK" I get the following message on the debugger.
~~~~~~~~~~
Thread 1 "gnucash" received signal SIGSEGV, Segmentation fault.
0x00007ffff7712f33 in gtk_widget_show (widget=0x5555569157a0) at
../gtk/ gtkwidget.c:4834
~~~~~~~
Then I do a "bt full" which apparently gets a back trace as follows:
~~~~~~
0 0x00007ffff7712f33 in gtk_widget_show (widget=0x5555569157a0) at
../ gtk/gtkwidget.c:4834
__inst = 0x5555569157a0
__t = Python Exception <class 'gdb.error'>: No type named TypeNode.
__r = <optimized out>
_g_boolean_var_23 = <optimized out>
parent = <optimized out>
#1 0x00007ffff7c7d8ab in gnc_payment_window_check_payment
(pw=0x55555677f580) at /run/build/gnucash/gnucash/gnome/dialog-
payment.c:316
conflict_msg = 0x7ffff7cdded8 <error: Cannot access memory at
address 0x7ffff7cdded8>
amount_deb = {num = 0, denom = 1}
amount_cred = {num = 5000, denom = 1}
enable_xfer_acct = <optimized out>
allow_payment = <optimized out>
selection = <optimized out>
c_result = <optimized out>
d_result = <optimized out>
#2 0x00007ffff68e1b32 in <emit signal '???' on instance ???>
(closure=0x5555568725b0, return_value=Python Exception <class
'gdb.MemoryError'>: Cannot access memory at address 0x7fffffff8de8
~~~~~~~~~~~
I got that one once. Then I tried twice again and the tests are here
(backtrace quite a bit longer)
https://drive.google.com/file/d/1EuFMFTDsOarFn57x1n7S01tsdDn2cezI/view?
usp=sharing
Subsequent times the backtrace is much longer but was the same each
time.
I hope that sheds some light?
kind regards
James
On 2025/10/13 18:57, John Ralls wrote:
OK, something strange is going on. Can you repeat the exercise a
couple more times and see if you always get the same error and
stack trace?
Regards,
John Ralls
On Oct 13, 2025, at 00:21, James Thorpe
<[email protected]> wrote:
In answer to your questions:
No - I don't have auto-save enabled. I save pretty often when I've
done something right and deliberately don't auto-save in case
something goes wrong so it's easy to recover to a previous point.
And yes, the error occurs when I assign payment from register...
specifically at the point where I click the "OK" after selecting a
customer and invoice.
I am working with a network file... which means the previous save
could on occasion be delayed a little I suppose if that action is
in a different thread and it could be in the middle of trying to
save when I perform the assign as payment bit?? Could that be it?
I could test by a) working with a local file and seeing if the
error does/ doesn't recur or b) waiting a longer time between
saves before assigning a payment.
On 2025/10/11 20:09, John Ralls wrote:
Interesting. The segfault in gtk_widget_show has nothing whatever
to do with the stack trace, which is deep in the midst of saving
your file. In the stack trace (which I’ve extracted below to show
the proximate cause) the XML backend is trying to create a new
text session with the value “string” and the memory allocator
encounters a corrupted chunk in its accounting. The most likely
cause of that would be something writing to memory that doesn’t
belong to it. The gtk_widget_show segfault is a read, so it’s not
to blame.
Do you have auto-save enabled and might it have fired while you
were in the middle of assigning the payment? And to make sure I’m
looking at the right place, this is assign as payment from a
transaction in the register, right?
Regards,
John Ralls
On Oct 11, 2025, at 08:09, James Thorpe
<[email protected]> wrote:
Thread 1 "gnucash" received signal SIGSEGV, Segmentation fault.
0x00007ffff7712f33 in gtk_widget_show (widget=0x5555560b01f0) at
../gtk/gtkwidget.c:4834
4834 g_return_if_fail (GTK_IS_WIDGET (widget));
Here is the stack trace - I hope it means something to someone
--- BEGIN STACK TRACE
------------------------------------------------------------
#5 0x00007041794a5765 in malloc_printerr
(str=str@entry=0x7041795b9fd3 "corrupted size vs. prev_size") at
malloc.c:5772
--Type <RET> for more, q to quit, c to continue without paging--c
#6 0x00007041794a6126 in unlink_chunk
(p=p@entry=0x56046304e600, av=0x7041795f1ac0 <main_arena>) at
malloc.c:1611
fd = <optimized out>
bk = <optimized out>
#7 0x00007041794a915a in _int_malloc
(av=av@entry=0x7041795f1ac0 <main_arena>, bytes=bytes@entry=120)
at malloc.c:4381
p = <optimized out>
iters = <optimized out>
nb = <optimized out>
idx = <optimized out>
bin = <optimized out>
victim = 0x56046304e600
size = 1104
victim_index = <optimized out>
remainder = <optimized out>
remainder_size = 976
block = <optimized out>
bit = <optimized out>
map = <optimized out>
fwd = <optimized out>
bck = <optimized out>
tcache_unsorted_count = <optimized out>
tcache_nb = <optimized out>
tc_idx = 6
return_cached = <optimized out>
#8 0x00007041794a9db4 in __GI___libc_malloc (bytes=120) at
malloc.c:3336
ar_ptr = 0x7041795f1ac0 <main_arena>
victim = <optimized out>
tbytes = <optimized out>
tc_idx = <optimized out>
#9 0x00007041792a7d4c in xmlNewText
(content=content@entry=0x70417859e64c "string") at ../tree.c:2303
cur = <optimized out>
--
--
James Thorpe
061 476 2775
[email protected]
_______________________________________________
gnucash-user mailing list
[email protected]
To update your subscription preferences or to unsubscribe:
https://lists.gnucash.org/mailman/listinfo/gnucash-user
-----
Please remember to CC this list on all your replies.
You can do this by using Reply-To-List or Reply-All.
--
--
James Thorpe
061 476 2775
[email protected]
_______________________________________________
gnucash-user mailing list
[email protected]
To update your subscription preferences or to unsubscribe:
https://lists.gnucash.org/mailman/listinfo/gnucash-user
-----
Please remember to CC this list on all your replies.
You can do this by using Reply-To-List or Reply-All.
