2022-12-09 GnuCash IRC logs

01:23:01 *** rakor has quit IRC
01:25:47 *** gandalf has joined #gnucash
01:37:55 *** bertbob has quit IRC
01:43:30 *** fell has quit IRC
01:44:50 *** fell has joined #gnucash
01:44:50 *** ChanServ sets mode: +o fell
01:48:26 *** bertbob has joined #gnucash
01:48:27 *** ChanServ sets mode: +v bertbob
01:55:59 *** gjanssens has joined #gnucash
01:55:59 *** ChanServ sets mode: +o gjanssens
01:57:54 *** gour has joined #gnucash
01:57:54 *** ChanServ sets mode: +v gour
02:12:59 *** gjanssens has quit IRC
02:15:06 *** palerider has quit IRC
02:17:05 *** gandalf has quit IRC
04:39:11 *** digimago has quit IRC
04:46:22 *** gandalf has joined #gnucash
05:30:36 *** gjanssens has joined #gnucash
05:30:36 *** ChanServ sets mode: +o gjanssens
07:34:37 *** gjanssens has quit IRC
07:50:16 *** gjanssens has joined #gnucash
07:50:16 *** ChanServ sets mode: +o gjanssens
07:54:10 *** gandalf has quit IRC
07:54:38 *** gandalf has joined #gnucash
08:21:18 *** gjanssens has quit IRC
08:37:37 *** gjanssens has joined #gnucash
08:37:37 *** ChanServ sets mode: +o gjanssens
08:39:20 *** chris has quit IRC
08:40:15 *** chris has joined #gnucash
08:40:15 *** ChanServ sets mode: +v chris
08:40:18 *** gncbot sets mode: +o chris
08:40:28 <chris> warlord: https://wiki.gnucash.org/wiki/FAQ#Q:_Why_does_the_Transaction_Report_.27Sign_Reversal.27_setting_not_work_on_subtotals
08:46:05 <warlord> chris, it was unclear that it was only subtotals that were affected.
09:44:19 *** chris has quit IRC
11:00:48 *** chris has joined #gnucash
11:00:48 *** ChanServ sets mode: +v chris
11:00:51 *** gncbot sets mode: +o chris
11:02:58 <chris> warlord: the FAQ describes the *only* "breaking" change that I'd introduced in the trep. one broken egg, lots of upgrades.
11:05:28 *** gandalf has quit IRC
11:10:03 *** djbrown has joined #gnucash
11:10:04 *** ChanServ sets mode: +v djbrown
11:17:05 *** djbrown has quit IRC
11:51:56 <jralls> gjanssens, IIRC you use KDE. Do you use Plasma or some other WM?
12:07:56 <gjanssens> jralls: I'm on Plasma
12:20:07 <gjanssens> jralls: anything particular you're interested in ?
12:31:27 <jralls> gjanssens Yeah, https://bugs.gnucash.org/show_bug.cgi?id=798587.
12:33:06 <jralls> One of its dupes, https://bugs.gnucash.org/show_bug.cgi?id=798688, adds that the selection created by ctrl-a only lasts for a moment.
12:34:47 <jralls> I noticed comment 11 suggests that it's only on X11, so if you're using Wayland that might be why it hasn't been driving you nuts.
12:35:35 <gjanssens> Alas, it's not driving me nuts because I don't use GnuCash currently :(
12:36:16 <gjanssens> But I'm on X11 and when I test it does show the same behaviour
12:37:01 <jralls> Oh, at all? I knew you use an ERP for the business but I thought you used GnuCash for your personal books.
12:37:51 <gjanssens> No, I currently don't keep personal books. There's not enough going on to manage privately.
12:38:15 <gjanssens> Almost feels like a confession... should I blush now ;) ?
12:38:43 <jralls> Maybe.;-)
12:38:51 <gjanssens> :blush:
12:39:12 <warlord> Wow!
12:39:57 <gjanssens> Anyway, the behaviour is indeed ugly. Do you have any idea where to start looking for the cause ?
12:40:56 <gjanssens> It's something that happened from time to time back when I was still actively using GnuCash. But apparently it has gotten way worse since then.
12:40:58 <jralls> Unfortunately my first guess would be KDE's selection code.
12:41:30 <jralls> That's a lot closer to the hardware than you're used to.
12:44:07 <jralls> There's something that we're doing in gnc_quickfill_cell_modify_verify or something nearby that's breaking the selection, but setting the trap for whatever it is has to be done in KDE.
12:46:16 <jralls> Another commenter on bug 798587 found that setting --log gnc.register.gnome=debug slowed things down enough that it worked, suggesting that there might be a race going on.
12:46:57 <jralls> Do you know if KDE keeps all the GUI interactions on a single thread like everybody else?
12:47:11 <gjanssens> Didn't we have a similar issue with setting xim for IM a few years back ?
12:47:43 <gjanssens> I notice on my machine xim is set for QT applications whereas GTK uses gtk-im-context-simple
12:47:59 <jralls> The thing I remember about XIM was a use-after-free in the Gtk XIM driver.
12:48:14 <gjanssens> I don't know if GUI interactions are single threaded in KDE
12:49:35 <gjanssens> Well, swapping im drivers doesn't make a difference. Was easy to test though.
12:53:31 <jralls> I hadn't thought of a IME interaction. The info about ctrl-a leads me away from that because no keystrokes are involved. Do you see that behavior too?
12:54:27 <jralls> That is, type ctrl-a in a Description and the selection highlights for a moment and then çlears.
12:54:40 <jralls> er, clears.
12:56:23 <gjanssens> No I can't reproduce that.
12:57:02 <gjanssens> The reporter is on Fedora 37, I'm on 36 still. Perhaps something has changed in the new release.
12:58:06 <gjanssens> I presume you use Gnome in your test boxes ? Are they using Wayland already or X11 still ?
13:05:04 <gjanssens> I do see quite a bit of variation on how many characters I can select before the autocompleted bit gets deselected.
13:05:16 <jralls> All my test VMs are Gnome, yes.
13:05:35 <gjanssens> Sometimes it's when I type the second character, sometimes on the third and occasionally on the 4th.
13:06:16 <gjanssens> I have been testing as follows: start typing until the autocomplete highlight is removed, hit ctrl-a, restart typing the same thing.
13:06:47 <jralls> I think I can set up KUbuntu VM pretty easily, but it might not be fast enough with the VM in the way. Only way to find out is to try, I guess.
13:07:11 <gjanssens> I have tried typing extremely slowly and as fast as I can. But the issue happens in both cases so perhaps VM speed may not matter.
13:07:17 <gjanssens> Perhaps it does.
13:07:51 <jralls> Try running GnuCash --debug. One commenter said that made it work right.
13:09:56 <gjanssens> Not on my system. I can consistently reproduce this (Fedora 36)
13:10:09 <gjanssens> I also ran under gdb, but no difference.
13:10:27 <gjanssens> Is there a source line you'd like me to set a breakpoint to evaluate something ?
13:12:13 <jralls> Try https://github.com/Gnucash/gnucash/blob/maint/gnucash/register/register-gnome/quickfillcell-gnome.c#L70, which is where gnc_quickfill_cell_direct_update figures out from the selection where to put the cursor.
13:15:39 <gjanssens> Ok, let's see what happens...
13:16:30 <jralls> Or maybe not. The switch block above it seems to return false unless the key code is one of alt-/, ctrl-tab, or ctrl-shift-tab.
14:28:41 <gjanssens> jralls: a bit of feedback on initial testing
14:29:47 <gjanssens> I started by breaking on gnucash_sheet_key_press_event_internal
14:30:03 <gjanssens> Stepped through it, but found nothing unusual.
14:30:36 <gjanssens> I got the faulty selection behaviour this way still
14:31:23 <gjanssens> Then I worked backwards from gnc_quickfill_cell_modify_verify and found it to be called from gnc_table_modify_update
14:31:31 <gjanssens> So I set a breakpoint on the latter.
14:32:07 <gjanssens> With this breakpoint in place I can no longer reproduce the faulty behaviour, suggesting a timing issue.
14:32:08 <jralls> gjanssens, OK. I set up a KUbuntu 22.10 VM, built GnuCash, and the problem doesn't reproduce for me. System Settings/About says I'm on X11.
14:33:00 <jralls> Yeah, the comments on the bug point that way too.
14:33:08 *** raeburn has quit IRC
14:34:02 <gjanssens> So I started looking furter and found gnc_table_modify_update to be triggered whenever gtk_entry_im_context_filter_keypress is called.
14:34:55 <gjanssens> gtk_entry_im_context_filter_keypress emits insert_text events on our GtkEntry while processing the keypresses
14:36:52 <gjanssens> Interestingly except for the first keypress, this event is triggered twice, once to reset the entry to original value and once to add a single character to the original value (the pressed key)
14:38:27 <gjanssens> Well, original_value but case preserving
14:39:49 <gjanssens> It seems if there's enough time between these two calls to the callback, everything works fine. If they trigger too fast, the entry gets messed up.
14:40:12 *** raeburn has joined #gnucash
14:40:12 *** ChanServ sets mode: +v raeburn
14:40:31 <gjanssens> jralls, is there a quick way to add a few miliseconds delay in the callback function ?
14:40:43 <gjanssens> Primarily as a test for my hypothesis
14:40:58 <jralls> Interesting. gtk_entry_im_context_filter_keypress is called at https://github.com/Gnucash/gnucash/blob/maint/gnucash/register/register-gnome/gnucash-sheet.c#L1834; there are two calls to gtk_entry_reset_im_context, one in gnucash_sheet_insert_cb and the other in gnucash_sheet_activate_cursor_cell. You could see if commenting any of those help.
14:41:34 <jralls> For a millisecond delay there's something like micro_sleet, give me a second to find it...
14:44:45 <jralls> It's usleep(3) and nanosleep(2). The first does microseconds, the second nanoseconds.
14:58:38 <gjanssens> I didn't disable the extra gtk_entry_reset_im_context lines you pointed at. Neither is triggered while typing.
14:59:37 <gjanssens> jralls: however if I add a 1000µs sleep in gnucash/register/register-core/table-allgui.c:1294, the problem goes away.
14:59:49 *** palerider has joined #gnucash
14:59:50 <gjanssens> I can't reproduce with that small delay.
15:00:51 <jralls> In a modern computer 1000us is an *enormous* delay, 10K-100K instructions.
15:01:48 <gjanssens> True.
15:02:09 <gjanssens> Testing with 100µs I can still trigger the bug.
15:03:31 <gjanssens> So using an arbitrary delay is just that - arbitrary. OTOH it seems this only triggers on fast systems, so adding the small delay may help as slower systems didn't have the issue anyway.
15:03:47 <gjanssens> It is just a work around, but I have nothing better right now.
15:04:35 <gjanssens> And that's all I can do for today as well. I have to leave...
15:05:06 <jralls> OK, thanks a ton for working that out. I need to think about this, it's clearly a concurrency issus.
15:11:50 <jralls> gjanssens, when you have a chance could you try moving the usleep() call to gnucash-sheet.c#1191 and if that works walk it down the function until it doesn't or you run out of function?
15:12:33 *** palerider has left #gnucash
15:25:27 *** gandalf has joined #gnucash
15:25:38 *** gjanssens has quit IRC
15:53:51 <jralls> @tell gjanssens On the gnc_table_update_modify delay, the delete-text and insert-text signals are emitted one after the other in gtk_entry_delete_text and gtk_entery_insert_text, each called in succession by gtk_entry_enter_text via gtk_editable_delete_selection and gtk_editable_insert_text respectively, https://gitlab.gnome.org/GNOME/gtk/-/blob/gtk-3-24/gtk/gtkentry.c#L6149.
15:53:51 <gncbot> jralls: The operation succeeded.
16:22:57 *** gjanssens has joined #gnucash
16:22:57 *** ChanServ sets mode: +o gjanssens
16:25:41 <gjanssens> jralls: if it's at 1194, it breaks again.
16:25:41 <gncbot> gjanssens: Sent 31 minutes ago: <jralls> On the gnc_table_update_modify delay, the delete-text and insert-text signals are emitted one after the other in gtk_entry_delete_text and gtk_entery_insert_text, each called in succession by gtk_entry_enter_text via gtk_editable_delete_selection and gtk_editable_insert_text respectively, https://gitlab.gnome.org/GNOME/gtk/-/blob/gtk-3-24/gtk/gtkentry.c#L6149.
16:30:13 <jralls> gjanssens, Hmmm. And in between is gnucash_sheet_set_entry_value that blocks the insert and delete handlers, sets the text on the entry, and unblocks them.
16:30:18 <gjanssens> jralls: perhaps we should block these signals while processing our key presses. Which means we should block them before calling gtk_entry_im_context_filter_keypress in gnucash_sheet_key_press_event_internal
16:30:55 <gjanssens> Oh, so that's doing what I suggested in a way and not working.
16:35:19 <gjanssens> Right after that there's g_signal_stop_emission_by_name
16:35:24 <jralls> Not exactly. Blocking the signals in gnucash_sheet_key_press_event would turn off the signal handlers completely.
16:36:03 <jralls> g_signal_stop_emission_by_name prevents any other handler from getting the signal.
16:41:06 *** gandalf has quit IRC
16:41:52 <jralls> Signal handling is supposed to be sequential but something is happening in that millisecond that gets broken if the handlers are blocked. Weird.
16:47:55 <jralls> If I comment out the call to gnucash_sheet_set_entry_value the selection doesn't get deleted so it imitates the problem: typing op in a reg with an Opening Balance transaction gets me Oppening Balance.
16:53:23 <gjanssens> Last bit I wanted to mention though perhaps no longer important: if I set the delay to only 100µs (and in the original spot), I can reproduce the faulty selection behaviour on ctrl-a.
16:53:30 <gjanssens> Good luck with further debugging.
16:53:37 <gjanssens> I'm off to bed now...
16:56:02 <jralls> gtk_editable_(insert|delete)_text just call gtk_entry_(insert|delete)_text and they just emit the signal.
16:56:09 <jralls> Goodnight, and thanks again.
16:58:21 *** gour has quit IRC
16:59:40 <gjanssens> You're welcome :)
17:17:00 *** gjanssens has quit IRC
17:52:35 *** CDB-Man has joined #gnucash
17:52:36 *** ChanServ sets mode: +v CDB-Man
19:24:14 *** bertbob has quit IRC
19:25:42 *** bertbob has joined #gnucash
19:25:43 *** ChanServ sets mode: +v bertbob
19:54:14 *** warlord has quit IRC
20:41:56 *** warlord has joined #gnucash
20:42:10 *** warlord2 has joined #gnucash