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]> 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]> 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]> >>>>>> 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] >>> > > > _______________________________________________ > 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. _______________________________________________ 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.
