[GNC] Regular crashes on Linux Mint when assigning payment
James Thorpe
James at fusionsystems.co.za
Tue Oct 14 03:11:35 EDT 2025
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
>
--
--
James Thorpe
061 476 2775
James at fusionsystems.co.za
More information about the gnucash-user
mailing list