James, Thanks for following up.
Regards, John Ralls > On Oct 15, 2025, at 01:27, James Thorpe <[email protected]> wrote: > > 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 <[email protected]> >>> <mailto:[email protected]> wrote: >>> >>> 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 <[email protected]> >>>>>> <mailto:[email protected]> 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 <[email protected]> >>>>>>>> <mailto:[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] <mailto:[email protected]> >>>>> >>> >>> >>> _______________________________________________ >>> gnucash-user mailing list >>> [email protected] <mailto:[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. >> > -- > -- > James Thorpe > 061 476 2775 > [email protected] <mailto:[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.
