09:18 <jgeboski> https://github.com/dequis/bitlbee/commit/5e47629ad88437fddc008027d1a1a4517997a056
09:18 <jgeboski> check my changes to the function in bee_chat.c
09:18 <jgeboski> not 100% on that

[...]

10:16 <jgeboski> I need to fix a message duping issue
10:16 <jgeboski> with that patch
--- Log closed Mon Dec 15 11:56:18 2014

--- Log opened Tue Dec 16 08:47:41 2014
08:47 <jgeboski> so, that patch
08:48 <jgeboski> I track the group chats with their groupchat pointer
08:48 <jgeboski> is that bad?
08:48 <jgeboski> should I do it by the title?
08:48 <jgeboski> because
08:48 <dx> groupchats have no ->data or equivalent?
08:49 <jgeboski> prpl->chat_join is getting called more than once for the same title
08:49 <jgeboski> with different point values
08:49 <dx> huh
08:49 <jgeboski> well
08:49 <jgeboski> I same i mean
08:49 <jgeboski> but it leads to me creating more than once grouchat
08:49 <jgeboski> both of which print to the same channel
08:50 <jgeboski> and no, ->data won't work
08:50 <jgeboski> I need them stored so when I get input on a filter, I know which channels to output to
08:51 <jgeboski> but this is what leads to the duplication bug I was telling you about
08:51 <jgeboski> I think it has to do with my client
08:51 <jgeboski> but bitlbee should be accounting for this
08:54 <jgeboski> it's when my client autoconnects and auto joins
08:54 <dx> ugh
08:57 <jgeboski> still poking around to ensure it's not just me being retarded
08:57 <jgeboski> just wanted to know if there were any known issues of such
09:00 <dx> there might be
09:00 <jgeboski> the first line of my prpl->chat join:
09:00 <jgeboski> g_print("Adding groupchat: %p, %p, %p, %p, %p\n", ic, room, nick, password, sets);
09:00 <jgeboski> Adding groupchat: 0x55555582a530, 0x55555583db70, 0x5555558127d0, (nil), 0x55555583d728
09:00 <jgeboski> Adding groupchat: 0x55555582a530, 0x55555583db70, 0x5555558127d0, (nil), 0x55555583d728
09:00 <dx> nice debugging bro
09:00 <jgeboski> now I will stack trace it
09:01 <jgeboski> first line of my prpl->chat_leave
09:01 <jgeboski> g_print("Removing groupchat: %p\n", c);
09:01 <jgeboski> Removing groupchat: 0x55555582a000
09:01 <jgeboski> clearly a memleak there
09:02 <dx> bro do you even valgrind
09:03 <jgeboski> https://pastebin.osuosl.org/13926/14187314/
09:04 <dx> ye looks familiar
09:06 <jgeboski> I am fairly certain this issue resides outside the scope of my modifications?
09:06 <dx> yeah
09:10 <jgeboski> my patch is pretty much good then
09:10 <jgeboski> just going to test memory leaks
09:10 <jgeboski> but I will fix the other issue
09:16 <jgeboski> if I set each channel to auto_join false
09:16 <jgeboski> that'd be a work around
09:16 <dx> indeed
09:17 <jgeboski> <@jgeboski> channel #gmuyaks set
09:18 <jgeboski> <@root> account = `twitter'
09:18 <jgeboski> <@root> auto_join = `false'
09:18 <jgeboski> well it already was
09:18 <jgeboski> lol
09:18 <jgeboski> that's depressing
09:20 <jgeboski> found the bug
09:20 <dx> yeah it only seems to apply on /reconnect
09:20 <jgeboski> https://github.com/dequis/bitlbee/blob/6340060/irc_channel.c#L434
09:20 <jgeboski> && should be ||?
09:21 <dx> well, both are !
09:21 <jgeboski> yeah
09:21 <jgeboski> it should be: !aj || ( ic->flags & IRC_CHANNEL_JOINED )
09:21 <jgeboski> remove the inverter on the flag check
09:21 <jgeboski> which is what the comment right below it conforms to
09:22 <dx> i'm not sure if the comment below is written correctly
09:22 <jgeboski> either way
09:22 <jgeboski> there is no condition explicitly for autojoin being false
09:23 <jgeboski> and it's suppose to cover that
09:23 <jgeboski> and it's not
09:23 <dx> !aj || ( ic->flags & IRC_CHANNEL_JOINED ) does look better
09:24 <jgeboski> logically
09:24 <dx> but test it a lot!
09:24 <jgeboski> I will
09:25 <jgeboski> but if you read it logically to the modified line, it does make sense
09:25 <jgeboski> as it is now, it does not
09:25 <dx> making sense is overrated
09:26 <jgeboski> also
09:26 <jgeboski> there should probably be another patch
09:26 <jgeboski> to guard against doubly joining
09:27 <jgeboski> as that does lead to memory leaks
09:27 <jgeboski> and potentially other bad things
09:28 <dx> sure
10:08 <jgeboski> https://github.com/dequis/bitlbee/commit/ad0e032ff66e5af04891aba562e7a07c1e6b4017
10:08 <jgeboski> still need to test
10:12 <jgeboski> definitely resolves the issues I was having