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.
