2017-08-17 GnuCash IRC logs
00:32:43 *** Mechtilde has joined #gnucash
00:37:07 *** bhardwajs has joined #gnucash
00:45:22 *** fiddlerwoaroof has quit IRC
00:47:14 *** bhardwajs has quit IRC
00:47:44 *** fiddlerwoaroof has joined #gnucash
00:48:28 *** bhardwajs has joined #gnucash
00:51:11 *** fiddlerwoaroof has quit IRC
00:53:02 *** fiddlerwoaroof has joined #gnucash
01:16:31 *** jotrago has quit IRC
01:38:29 *** Mechtilde has quit IRC
02:14:20 *** bhardwajs has quit IRC
02:15:45 *** bhardwajs has joined #gnucash
02:52:20 *** bhardwajs has quit IRC
03:06:40 *** gjanssens has joined #gnucash
03:06:40 *** ChanServ sets mode: +o gjanssens
03:07:20 <gjanssens> .
03:07:20 <gncbot> gjanssens: Sent 10 hours and 33 minutes ago: <jralls> Re: ustar. OK if that's good enough, though ISTM all of our users will be using recent enough gnutar or bsdtar that posix would work too.
03:07:21 <gncbot> gjanssens: Sent 10 hours and 32 minutes ago: <jralls> That means you can un-shorten the import-export subdir names if you like. I shortened them a few years ago to fit in the v7 99-character limit.
03:32:55 *** cyphase has joined #gnucash
03:43:09 <gjanssens> @tell jralls_afk I was being conservative on tar as I wasn't sure about our Windows build. ustar gives us 256 characters for file paths. That seems sufficient for the time being.
03:43:09 <gncbot> gjanssens: The operation succeeded.
03:43:28 *** jralls_afk is now known as jralls
03:43:30 <jralls> .
03:43:42 <gjanssens> I was just thinking that wouldn't work :)
03:43:43 *** jralls is now known as jralls_afk
03:43:45 <jralls_afk> .
03:43:45 <gncbot> jralls_afk: Sent just now: <gjanssens> I was being conservative on tar as I wasn't sure about our Windows build. ustar gives us 256 characters for file paths. That seems sufficient for the time being.
03:43:52 <gjanssens> That does :D
03:43:54 *** jralls_afk is now known as jralls
03:44:45 <jralls> Yeah, my fingers got ahead of my brain.
03:45:01 <gjanssens> Are you still touring in Europe ?
03:45:34 <jralls> ustar gives us *up to* 256 characters depending on where it can break the path into segments.
03:45:46 *** fabior has joined #gnucash
03:46:11 <gjanssens> Yes, that's more exact...
03:46:18 <jralls> Yeah, we're in Prague until Tuesday then London for a couple of days, back in California in a week.
03:46:48 <gjanssens> Nice. I really enjoyed Prague a couple of years back.
03:47:38 <gjanssens> You may have seen the mail I just sent about dbi backend loading ?
03:48:13 <jralls> I saw the notification, haven't looked at it yet. I'll do that now.
03:48:32 <gjanssens> If you have time. You're on holidays!
03:50:01 <jralls> I'm working on the KVP problem from yesterday ATM. I'll answer your email on the list so that everyone else isn't left hanging.
03:51:01 <gjanssens> Sure, that's the preferred way forward. The dbi issue can come after KVP as well.
04:04:29 <jralls> Actually the KVP issue is breaking dbi, at least on Mac. Can you check a recent test log and see if test-backend-dbi ran successfully?
04:09:21 *** fekepp has joined #gnucash
04:10:38 <jralls> So Vicki is now sufficiently caffienated and wants to head out. Be back after supper.
04:10:45 *** jralls is now known as jralls_afk
04:11:58 *** mrklintscher4 has joined #gnucash
04:13:21 <gjanssens> jralls_afk: enjoy your day. test-backend-dbi is failing here as well
04:18:11 *** pilotauto has quit IRC
04:19:38 *** fekepp has quit IRC
04:43:24 *** jotrago has joined #gnucash
05:05:27 *** User has joined #gnucash
07:02:56 *** fabior has quit IRC
07:08:23 *** Jimraehl1 has joined #gnucash
07:12:46 *** bertbob has quit IRC
07:28:03 *** bertbob has joined #gnucash
07:28:21 *** storyjesse has joined #gnucash
07:29:10 <warlord> .
07:38:04 *** jonas has quit IRC
07:38:15 *** jonas has joined #gnucash
07:46:58 *** rickoehn has joined #gnucash
08:30:12 *** Chris has joined #gnucash
08:33:59 *** Chris has quit IRC
08:38:13 *** Chris has joined #gnucash
08:56:43 *** lmat has quit IRC
08:56:48 *** lmat has joined #gnucash
08:56:58 <lmat> @op
08:56:58 <gncbot> lmat: Error: You don't have the #gnucash,op capability. If you think that you should have this capability, be sure that you are identified before trying again. The 'whoami' command can tell you if you're identified.
09:06:12 <warlord> gjanssens: FYI, no errors from the docs build overnight.
09:10:07 <gjanssens> warlord: good
09:15:02 *** fabior has joined #gnucash
09:35:18 <lmat> @tell jralls So the KVP_Value problem is not dereferencing null, but perhaps that KVP_Value has been deleted?
09:35:18 <gncbot> lmat: The operation succeeded.
09:51:51 *** fabior has quit IRC
10:04:59 *** Mechtilde has joined #gnucash
10:06:39 *** fabior has joined #gnucash
10:18:27 *** bhardwajs has joined #gnucash
10:37:22 *** benno has joined #gnucash
10:38:00 *** levi has joined #gnucash
10:38:06 <levi> hi
10:38:06 <gncbot> levi: Sent 1 week, 0 days, 22 hours, and 2 minutes ago: <fell> About FRS 105...: Noboby provided them until now. See https://wiki.gnucash.org/wiki/Account_Hierarchy_Template for how to create them.
10:46:38 *** bertbob has quit IRC
10:57:43 *** Mechtilde has quit IRC
11:15:26 *** bertbob has joined #gnucash
11:18:33 *** ArtGravity has joined #gnucash
11:18:34 *** bertbob has quit IRC
11:21:58 *** Chris has quit IRC
11:25:51 *** Chris has joined #gnucash
11:32:22 *** bhardwajs has quit IRC
11:34:38 *** bertbob has joined #gnucash
11:37:44 *** bertbob has quit IRC
11:44:11 *** Chris has quit IRC
11:52:14 <levi> thx !
11:53:55 *** bertbob has joined #gnucash
12:06:34 *** Mechtilde has joined #gnucash
12:06:59 *** benno has quit IRC
12:09:55 *** jotrago1 has joined #gnucash
12:10:27 *** jotrago has quit IRC
12:10:28 *** jotrago1 is now known as jotrago
12:17:46 *** jotrago1 has joined #gnucash
12:18:22 *** jotrago has quit IRC
12:18:24 *** jotrago1 is now known as jotrago
12:20:49 *** d-rock has joined #gnucash
12:26:41 *** storyjesse has quit IRC
12:37:12 *** mrklintscher4 has quit IRC
12:46:03 <lmat> @tell jralls I think I reproduced the problem. I got that forced_return bit.
12:46:03 <gncbot> lmat: The operation succeeded.
12:47:39 <lmat> @tell jralls from build/bin, I ran GNC_BUILDDIR=.. GNC_UNINSTALLED=y gdb ./test-backend-dbi
12:47:39 <gncbot> lmat: The operation succeeded.
13:07:57 *** jotrago has quit IRC
13:29:37 *** jralls_afk is now known as jralls
13:29:38 <jralls> .
13:29:38 <gncbot> jralls: Sent 3 hours and 54 minutes ago: <lmat> So the KVP_Value problem is not dereferencing null, but perhaps that KVP_Value has been deleted?
13:29:39 <gncbot> jralls: Sent 43 minutes ago: <lmat> I think I reproduced the problem. I got that forced_return bit.
13:29:40 <gncbot> jralls: Sent 41 minutes ago: <lmat> from build/bin, I ran GNC_BUILDDIR=.. GNC_UNINSTALLED=y gdb ./test-backend-dbi
13:32:13 <jralls> lmat: The takeaway I get from test-backend-dbi is that the KVPValue comparison fails. That tells me that I either did something wrong or missed a step in gnc-slots-sql.cpp, so that's my current debugging focus.
13:34:42 *** mrklintscher4 has joined #gnucash
13:37:09 *** mrklintscher5 has joined #gnucash
13:37:49 *** mrklintscher5 has quit IRC
13:39:27 *** mrklintscher4 has quit IRC
13:41:16 *** mrklintscher4 has joined #gnucash
13:41:36 <lmat> jralls: It's such a strange problem (I'm currently looking at it with a debugger)
13:46:17 <lmat> Oh yeah, from what I can tell, it's a "child" account which has a kvp frame with one element "placeholder" whose value is messed up.
13:46:22 *** mrklintscher5 has joined #gnucash
13:47:23 *** mrklintscher5 has quit IRC
13:48:55 *** Mechtilde has quit IRC
13:48:58 *** mrklintscher4 has quit IRC
13:49:59 <jralls> lmat: Yeah, that's what it looks like to me... I'm leaning towards the actual value is never set.
13:50:21 <lmat> jralls: It certainly looks like initialized data...
13:50:38 *** mrklintscher5 has joined #gnucash
13:51:28 *** mrklintscher6 has joined #gnucash
13:51:48 <jralls> It looks like partly inited data to me. Else why would the datatype be 32 bits instead of 4?
13:52:05 *** Mechtilde has joined #gnucash
13:53:43 *** mrklintscher5 has quit IRC
13:59:12 *** mrklintscher7 has joined #gnucash
13:59:20 *** mrklintscher6 has quit IRC
14:05:22 *** Mechtilde has quit IRC
14:15:44 *** frakturfreak has joined #gnucash
15:06:02 *** fabior has quit IRC
15:22:30 *** O01eg has quit IRC
15:22:42 *** O01eg has joined #gnucash
15:37:01 <lmat> jralls: I've only had a quick look at this... slot_info_copy has newSlot->pKvpValue = pInfo->pKvpValue; Is that right?
15:40:36 <jralls> lmat: Umm, is pKvpValue a shared_ptr? If it's not then newSlot could end up with a dangling ptr...
15:40:56 <lmat> jralls: KvpValue*
15:41:23 <lmat> jralls: Sure, or the existing one could end up with a dangling pointer...depends on which one gets destroyed first.
15:41:36 <lmat> jralls: I'm thinking it should be a proper copy...
15:42:04 <jralls> That could be a problem then. I have a dim memory of discussing this before when you were writing it and there was some reason you couldn't use a shared_ptr, but I don't remember why.
15:43:00 <lmat> jralls: I added registration functionality to kvp value: every time an object is created, it is registered, and upon deletion, it is removed from the list.
15:43:40 <lmat> jralls: When the problem happens, I unwind back to KvpValueImpl::get_type() and take a look at that list, and "this". "this" should be on the list, but isn't.
15:43:53 <lmat> Which suggests a dangling pointer problem. I'll change to copy and see if this is addressed.
15:44:36 <jralls> The other correct model would be if pInfo explicitly transfers ownership of pKvpValue to newSlot. Ideally that would have pKvpValue be a unique_ptr, but it could also be a regular KvpValue* with documentation.
15:45:22 <lmat> jralls: The function is slot_info_copy, so it shouldn't be a transfer.
15:48:30 <jralls> Ah, so I'm remembering wrong because this is code I wrote.
15:58:50 <jralls> But meanwhile I'm looking at set_slot_from_value and it looks like it's the pInfo->pKvpFrame that's getting corrupted, not the KvpValue. Of course that's also raw-ptr copied in slot_info_copy so that might be an issue.
16:11:38 <lmat> running GNC_BUILDDIR=.. GNC_UNINSTALLED=y valgrind ./test-backend-dbi 2>&1 | less
16:17:32 <jralls> lmat: ?
16:17:43 <lmat>
16:18:18 <lmat> It shows that guids are being free()ed (when they're allocated with new), but more to the point, several invalid reads.
16:18:29 <lmat> That is, reads from free()ed memory.
16:19:27 <lmat> Oh, Invalid read of size 4 at boost::variant<long, double,......
16:22:25 <lmat> I also added if (std::find(extant.begin(), extant.end(), &two) == extant.end()) std::cout << "\n\nusing non-extant kvpvalue\n\n";
16:22:28 <jralls> OK. That does sound like a problem but I still think that there's a deeper problem that the slots aren't always being created correctly from the database.
16:22:54 <lmat> yup, sounds possible.
16:23:59 <lmat> (added that in kvp value compare. It confirms that kvpvalues are being used that aren't allocated)
16:24:20 <jralls> I say that because debugging into slot creation doesn't seem to produce a valid KvpValue in memory.
16:24:53 <jralls> Weren't allocated or have been deleted? Or can you tell?
16:26:48 <lmat> jralls: Can't tell. Of course, there's no for-sure way to tell because there's no difference. The fact that a kvp_value used to exist at a particular part in memory doesn't mean that it's the same "instance" being referenced.
16:27:20 <lmat> Whether that memory location was retrieved by an earlier call to new, or just fabricated...
16:28:00 <lmat> jralls: Where are slots created?
16:28:54 <jralls> Can you be more specific?
16:31:58 <lmat> I'll create another list of deleted kvp values to see if it used to exist, got deleted, and is being de-referenced again, or it's just a bad address.
16:32:33 <jralls> As for "fabricated" ptrs, the compiler will catch uninitialized pointers and anyway they'll usually cause a segfault because they're unlikely to point to a valid location. A pointer to a no-longer-valid stack variable won't segfault and valgrind won't know about it either.
16:33:45 <lmat> jralls: Yeah, it's hard to imagine the application fabricating an address good enough not to cause a segmentation fault, but still invalid. Most likely we are de-referencing a dangling pointer.
16:37:12 <lmat> Yes, I see the address in the list of deleted kvpvalueimpls.
16:41:50 *** frakturfreak has quit IRC
16:44:27 <jralls> Not surprised.
16:47:23 <jralls> But it doesn't appear from examination that slot_info_copy is to blame for deletes. It doesn't seem to ever be returned and the slot_info_t that it copies (and hence the KvpFrame* and KvpValue*) seem to always live longer.
16:49:09 <lmat> Where are slots created?
16:51:00 <jralls> All over the place.
16:51:51 <jralls> That's why I asked you to be more specific earlier.
16:52:49 <jralls> If you mean during load, they're created every time a FRAME record is encountered in the slots table.
16:54:10 <lmat> jralls: What code is responsible for allocing a gnc_slot_t ?
16:55:36 <jralls> There's no such thing as a gnc_slot_t. "slot" is just another name for KvpFrame.
16:55:57 <lmat> I mean slot_info_t (gnc_slot_info_t?)
16:56:10 <lmat> (but thanks for that clarification, too!)
16:57:49 <jralls> slot_info_t is a private struct in gnc-slots-sql.cpp. It's used for holding state while iterating through the items in a slot-table row.
16:59:51 <lmat> Where are they allocated? I only see new slot_info_t in slot_info_copy.
17:03:46 <jralls> They're stack variables in the root functions, e.g. gnc_sql_slots_load.
17:04:08 <lmat> oh, okay
17:04:41 <lmat> Oh wait, so that "new slot_info_t" in slot_info_copy probably shouldn't be there X|
17:07:01 <lmat> Oh, it's deleted. nevermind, I'll look more
17:10:43 <lmat> jralls: Heading out, talk to you tomorrow. Have fun on vacation!
17:11:06 <jralls> OK. My bedtime anyway. Good night!
17:11:34 *** jralls is now known as jralls_afk
17:38:52 *** benno has joined #gnucash
17:43:46 *** benno has quit IRC
17:51:35 *** rickoehn has quit IRC
18:20:40 *** Kaell has joined #gnucash
18:30:07 *** Kaell has quit IRC
18:30:36 *** Kaell has joined #gnucash
18:33:27 *** pilotauto has joined #gnucash
18:43:43 *** gjanssens has quit IRC
18:47:37 *** ArtGravity has quit IRC
20:42:10 *** levi has left #gnucash
20:48:11 *** User has quit IRC
22:19:24 *** kael has joined #gnucash
23:20:29 *** kael has quit IRC
23:38:54 *** bhardwajs has joined #gnucash
23:45:10 *** mrklintscher7 has quit IRC
23:54:56 *** storyjesse has joined #gnucash