[GNC] Regular crashes on Linux Mint when assigning payment

Tue Oct 14 11:51:31 EDT 2025

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 <James at fusionsystems.co.za> 
>>> 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 <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
>>