[GNC] Regular crashes on Linux Mint when assigning payment

Wed Oct 15 04:27:27 EDT 2025

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 <sh025622 at gmail.com> 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 
>>>>> <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
>>>>
>>
>>
>> _______________________________________________
>> gnucash-user mailing list
>> gnucash-user at gnucash.org
>> 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
James at fusionsystems.co.za