Hi James,
Based on the call stack, I suspect this issue was resolved on October 13
by
https://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.
