[GNC] Regular crashes on Linux Mint when assigning payment

[James Thorpe]

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 <James at fusionsystems.co.za> 
>> 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 at 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 at entry=0x56046304e600, 
>> av=0x7041795f1ac0 <main_arena>) at malloc.c:1611
>>         fd = <optimized out>
>>         bk = <optimized out>
>> #7  0x00007041794a915a in _int_malloc (av=av at entry=0x7041795f1ac0 
>> <main_arena>, bytes=bytes at 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 at entry=0x70417859e64c "string") at ../tree.c:2303
>>         cur = <optimized out>
>>
>
-- 
--
James Thorpe
061 476 2775
James at fusionsystems.co.za