gistfile1.irclog

# logs from #irssi, 2014-03-19
# cleaned up to remove unrelated comments, empty lines added for readability where relevant
# i joined the channel in the middle of it to ask about something else

01:25 < tinypoodle> further trial shows the bug being triggered with any string after any amount of empty spaces at start of line, whenever hitting tab while cursor is not positioned after any character of string (i.e. at any position of empty space *or* on first char in string)
01:26 < tinypoodle> not sure  if the description is fully clear...
01:28 < tinypoodle> the oddish part is that ineach case the cursor jumps to end of line instantly
01:28 < dx> tinypoodle: what am i supposed to see when i do what you described there?
01:29 < tinypoodle> dx: 3 lines of error messages,  but only when done in status window
01:29 < dx> oh, yeah, i can reproduce that
01:30 < dx> looks fun
01:30 < tinypoodle> 4 out of 5 can reproduce so far
01:34 < dx> just installed a clean irssi with debug symbols, doesn't happen there..
01:36 < tinypoodle> heisenbug??
01:36 < tinypoodle> debug symbols neutralizing the bug?
01:36 < dx> nah, it's also on a completely different host with a completely different config, don't blame the debug symbols yet
01:37 < tinypoodle> < bcode> I've been able to reproduce this both on my (somewhat script-heavy 0.8.15) irssi instance I actually use and an entirely pristine 0.8.16-rc1
01:38 < dx> installed without debug symbols, still not happening in that host. how annoying
01:39 < tinypoodle> the plot thickens
01:40 < dx> but knowing that it also applies to clean configs is very useful
01:41 < tinypoodle> next logical step might be with debug symbols on a host where bug has been reproducible
01:42 < tinypoodle> I _think_ stock debian here
01:43 < dx> used exactly the same irssi binary in the same host with a different unix user account, not happening
01:43 < dx> (the other user has no config at all)
01:49 < tinypoodle> dx: you mean on same host there is case where is reproducible and othercase where is not?
01:50 < dx> tinypoodle: yep
01:50 < tinypoodle> dx that doesnt help =/
01:51 < tinypoodle> like we have a big range of obvious differences excluded by now

02:01 < dx> well, the relevant code is fe-common/core/completion.c line 234 (for 0.8.15), startpos/pos is 18, wordlen/string->len is 0

02:03 < dx> __PRETTY_FUNCTION__ = "beeps\000beep_msg"
02:03 < dx> lolwhat
02:05 < dx> i'm just going to ignore that since my debug symbols are crap. i'm surprised it shows the right line numbers and some variables

02:29 < dx> tinypoodle: okay i think i got something interesting out of this
02:30 < dx> tinypoodle: when you do tab at the start of a line in the status window, it completes with stuff like "/msg -server nickname". when you do tab elsewhere, it has an empty completion list
02:33 < tinypoodle> I can tab complete in channels too
02:34 < dx> uhhh... yeah you're right. derp
02:34 < tinypoodle> and identical output
02:35 < dx> oh wait hold on, what is this
02:35 < tinypoodle> is it a bird?
02:35 < dx> press space then tab
02:35 < dx> in normal channels it doesn't complete to anything, in the status window it does
02:35 < tinypoodle> that does nuffin
02:36 < tinypoodle> true
02:36 < dx> well, the abscence of a complist there is what makes it not show the error
02:39 < dx> in my other clean irssi that doesn't have this issue, it has an empty complist in the status window too
02:42 < tinypoodle> ohhh
02:43 < tinypoodle> just because there is no data available yet to be completed??
02:43 < dx> yeah, i think so
02:43 < tinypoodle> "bug does not affect virgins"
02:44 < dx> haha what

02:45 < dx> hell yeah, managed to reproduce it in the clean irssi \o/
02:45 < dx> you need to receive at least two private messages
02:46 < dx> two private messages from two different nicks, i mean
02:46 < tinypoodle> < bcode> if you type just <tab> without *anything* else (no spaces or anything) in the status window, does that complete to something like /msg nick? < billnye> yes, /msg -FreeNode raj
02:47 < tinypoodle> so that does still not explain why billnye cannot reproduce
02:47 < tinypoodle> dx why two?
02:49 < dx> dammit, it's not happening anymore
02:49 < dx> tinypoodle: now i'm not sure why two, iirc it didn't happen with a single one

02:51 < dx> yeah, only one item in that complist is needed, and i can reproduce it semi-reliably now (the "it's not happening" might be my own mistake)
02:55 < tinypoodle> ah

02:55 < tinypoodle> ohh, there *is* a diff status vs. chan
02:56 < tinypoodle> without empty space completion is same in status and chan
02:56 < tinypoodle> with empty space in chan would complete to a nick joined
02:57 < tinypoodle> line starting with empty space, I mean
02:58 < tinypoodle> space+d+tab --> dx
02:58 < dx> the code that says /* empty space at the start of line */ in completion.c doesn't make sense to me
02:58 < dx> if it detects empty space, it does wordstart += strlen(wordstart);
02:59 < dx> which... moves wordstart to the end of the line
02:59 < dx> it becomes ""
02:59 < tinypoodle> the empty space seems to be essential to triggering the bug
03:00 < tinypoodle> and when bug occurs, pointer is moved to end of line
03:00 < tinypoodle> s/pointer/cursor/

03:20 < dx> "startpos = strlen(linestart)+1;"
03:20 < dx> wtf are you doing irssi

03:38 < tinypoodle> unfortunately I wouldnt understand C =/
03:39 < dx> don't worry, i don't understand this either
03:41 < tinypoodle> =/
03:42 < tinypoodle> "+1" looks like it could be related
03:43 < dx> (i actually know C, it's just that it's slightly confusing)
03:44 < dx> i mean, we already know something isn't working as expected, but since i didn't write this, i don't know how it's expected to behave
03:45 < tinypoodle> I dont think its expected to print 3 error messages
03:45 < tinypoodle> which are rather adult rated
03:45 < dx> haha
03:46 < tinypoodle> "critical g_string_insert" is not most suitable for underage users

03:47 < dx> btw, i'm pretty sure this is harmless
03:48 < dx> i'm only debugging it for fun and procrastination purposes
03:49 < tinypoodle> I'm pretty sure I would never have learned about it without hanging out in #irssi
03:49 < tinypoodle> < tinypoodle> bcode: why you find bugs which noone ever would run into?  < bcode> tinypoodle: by accident :P
03:50 < Dirm> yeah wonder how long that's been around
03:51 < tinypoodle> my estimate being that its extremely rarely triggered in the wild

03:52 < dx> sometimes i'm managing to get the input box in a state that looks like it should have the bug, but actually completes a nick at the beginning of the line
03:53 < tinypoodle> in status window?
03:53 < dx> yup, all the same conditions
03:53 < tinypoodle> hmm, I tried many times and bug was always reproduced
03:54 < dx> i'm just repeating the same thing a bunch of times, going over the debugger and checking different variables each time
03:54 < dx> i could have done something wrong, but the input box looked okay

03:56 < dx> oooh, i know what happened
03:57 < dx> had a single whitespace at the end of the line
03:57 < tinypoodle> can reproducea
03:57 < tinypoodle> -a
03:58 < tinypoodle> no, wait...
03:59 < tinypoodle> that results in tab complete with string appended, no?
03:59 < dx> yeah
03:59 < tinypoodle> different manifestation of bug
03:59 < tinypoodle> no error msgs
03:59 < dx> true, that's buggy behavior too
03:59 < tinypoodle> but unexpected and nonsensical behavior
04:00 < dx> so basically the code that checks if the last character is a space is what sets a "pos" (from the error) bigger than the string length (also from the error)
04:01 < dx> err.. i mean.. if the last char isn't a space, it goes there, and sets a nonsense position
04:01 < dx> but even if it doesn't go there, there's still some nonsense
04:02 < dx> i'm just going to blame the code that says "/* empty space at the start of line */"
04:03 < tinypoodle> the cursor position behaves differently in the 2 manifestations
04:04 < Dirm> well it only repros in query windows right?
04:04 < Dirm> so it's got to depend on the output of the complete word signal
04:05 < tinypoodle> perhpas that code is meant for correct behavior of distinguishing empty space in channel window, but as a side effect freaks out in status win??
04:05 < dx> Dirm: only in status windows, and yeah, if the complete word signal gives empty results, the code that throws the assertion error is never reached
04:05 < dx> you could have a script that always returns some crap to the complete word signal
04:06 < dx> (i imagine that would be very annoying)

04:09 < dx> okay, got an initial patch working
04:09 < tinypoodle> http://bugs.irssi.org/index.php?do=details&task_id=124 looks like it could have some affinity
04:10 < dx> oh, yeah, looks like the same bug
04:11 < dx> you could have ",,,,, aaaaa" with the cursor in the first a, and you get the same thing
04:11 < tinypoodle> yup,canreproduce
04:12 < dx> bah, my shitty initial patch doesn't fix this one :(
04:14 < tinypoodle> from a user perspective, I think a triple "critical" in bold red chars is a bit inadequate
04:14 < dx> lol

04:23 < dx> i guess we actually have two different bugs here
04:25 < tinypoodle> o rly
04:25 < tinypoodle> the plot thickens

05:04 < dx> tinypoodle: anyway it's 5am and i don't know what's going on anymore
05:04 < tinypoodle> well, it is very difficult to detect, but then easy to reproduce
05:05 < tinypoodle> who needs g-strings at 5 am...
05:06 < dx> ...oh i didn't even notice that
05:10 < dx> tinypoodle: if you see a real irssi developer™ around, tell them how to reproduce it (both cases), and that startpos in completion.c:190 is being set to values that are too high when *linestart != '\0'
05:10 < dx> (you can just copypaste that)
05:11 < dx> oh also here's my shitty patch http://ix.io/bae
05:24 < tinypoodle> I wouldnt know who is a real irssi developer(TM) here...
05:24 < vague> ahf
05:25 < tinypoodle> that... would prolly have highlighted them
05:30 < vague> It would

08:38 < Nei> bcode: http://bugs.irssi.org/index.php?do=details&task_id=124
08:43 < tinypoodle> Nei: < tinypoodle> http://bugs.irssi.org/index.php?do=details&task_id=124 looks like it could have some affinity
08:43 < tinypoodle> 4.5h ago ;)
08:43 < Nei> I didnt read the whole backlog sorry ;p
08:44 < Nei> that bug is there for 10+ years
08:44 < Nei> it's "just" some critical warnings though
08:45 < tinypoodle> given enough eyeballs, uniqueness of a bug is shallow :P
08:47 < tinypoodle> doesnt "critical"rather imply error than warning?
08:47 < tinypoodle> I dont think I ever heard about critical warnings
08:47 < tinypoodle> at least not when it comes to conventions of linux kernel
08:48 < Nei> it is critical if irssi crashes
08:48 < Nei> or the kernel oopses
08:48 < Nei> then its an error
08:48 < dx> < dx> btw, i'm pretty sure this is harmless    < dx> i'm only debugging it for fun and procrastination purposes
08:48 < Nei> or if it allows remote code execution then it should be fixed too
08:49 < dx> it's just concatenating strings in a weird way and getting a start position bigger than the length of the original string, but the glib functions catch that mistake and emit those warnings, so there's no real issue
08:50 < Nei> it's still something that should be fixed if you're positive about the patch maybe add it to the bug tracker>
08:52 < dx> the patch i made only fixes part of the nonsense, the main issue is in completion.c:190 but i'd rather not touch that because i have no idea when it's used like that