kitty segfaults when selecting in diff kitten #1578
Comments
|
Can you post a backtrace of the crash? On most linux distributions, it ouwld require: make debug I cannot reproduce with your description, on master, steps I tried:
Note that the diff kitten does not currently implement mouse |
|
ah, by selecting text upwards i meant selecting it and scrolling upwards with mouse wheel. |
|
You mean yo uare holdingdown the left mouse button and usingthe wheel at |
|
yep |
|
also it |
|
I cant get it to crash on my system running from aster while doing that. |
|
A backtrace from the crash would help. |
|
hmm, im having some problems with that, maybe because of my weird setup. i have im pretty clueless in debugging also segfault occurs on mouse button up |
|
uhh, if i understand correctly, i ran |
|
Is that with kitty master or some other version, the line numbers dont match current source code. |
|
well, i just cloned the git repo, you can see it in the paths |
|
okay, i think i ran it wrong. here is new backtrace. |
|
Hmm it's an lnlined function, which is making the backtrace somewhat less helpful. Can you edit lineops.h and remove the inline keyword on line 35 andthen re-build and get a new backtrace. |
|
uhhh |
|
Oh yeah forgot that this would generate a warning. OK do slightly more involved surgery in that case, apply this patch: diff --git a/kitty/screen.c b/kitty/screen.c
index c7a04296..22cce626 100644
--- a/kitty/screen.c
+++ b/kitty/screen.c
@@ -1567,19 +1567,33 @@ range_line_(Screen *self, int y) {
return self->linebuf->line;
}
+static index_type
+xlimit_for_line_dbg(Line *line) {
+ index_type xlimit = line->xnum;
+ printf("xlimit at start: %u\n", xlimit);
+ if (BLANK_CHAR == 0) {
+ while (xlimit > 0 && (line->cpu_cells[xlimit - 1].ch) == BLANK_CHAR) xlimit--;
+ printf("xlimit before wide check: %u\n", xlimit);
+ if (xlimit < line->xnum && (line->gpu_cells[xlimit > 0 ? xlimit - 1 : xlimit].attrs & WIDTH_MASK) == 2) xlimit++;
+ printf("xlimit after wide check: %u\n", xlimit);
+ }
+ return xlimit;
+}
+
+
#define iterate_over_rectangle(start, end, line_func, y_type) { \
y_type min_y = MIN(start->y, end->y), max_y = MAX(start->y, end->y); \
index_type min_x = MIN(start->x, end->x), max_x = MAX(start->x, end->x); \
for (y_type y = min_y; y <= max_y; y++) { \
Line *line = line_func(self, y); \
- index_type xlimit = xlimit_for_line(line); \
+ index_type xlimit = xlimit_for_line_dbg(line); \
xlimit = MIN(max_x + 1, xlimit); \
index_type x_start = min_x;
#define iterate_over_region(start, end, line_func, y_type) { \
for (y_type y = start->y; y <= end->y; y++) { \
Line *line = line_func(self, y); \
- index_type xlimit = xlimit_for_line(line); \
+ index_type xlimit = xlimit_for_line_dbg(line); \
if (y == end->y) xlimit = MIN(end->x + 1, xlimit); \
index_type x_start = y == start->y ? start->x : 0;this hsould make the backtrace more useful and also print out some debugging info to stdout. |
|
|
And what was the output on stdout in the terminal from which you ran kitty |
xlimit statements repeated with same values |
|
Hmm that indicates there is some memory corruption happening somewhere, to that should confirm that my hypothesis is correct. Also could you make a |
|
|
Thanks, that does confirm my hypothesis. Sadly this is going to be a bear to debug without being able to reproduce and your video just shows you doing what I was. |
|
There may be some good news - I'm seeing a similar crash, without using any kittens on latest release. It's essentially some sort of mouse movement - not sure what it is exactly since I'm not doing it intentionally. I'll be pulling master, compiling with debug symbols and waiting for it to happen again. It may be - and this is a guess based on nothing - that this is where the original problem is. |
|
It's definitely not kitten related, since mouse selection happens purely |
|
Yes, I'm not able to repeatably trigger it either. Are you doing anything funky with threading+CPython? This sort of heisenbug is usually a race of some kind Thinking out loud here without having read any of the code, but is there a way to instrument the mouse support to keep a short history of events that can be extracted from a coredump subsequently? This would possibly give us reproducibility relatively cheaply. I'm thinking of a way I can help you debug this since I hate posting an issue and not posting a patch, especially for something I use daily, but frankly I don't have room in my brain for the kitty codebase at the moment - lovely, well-structured and easy to understand as I'm sure it must be ;) |
|
Nope, no threads. There is an I/O thread for processing input from child processes, but that has no relevance here and it's not a python thread in any-case. If you can trigger it sporadically, it might help if you simply built kitty with ASAN and ran it, that might give more hints about the cause. See https://sw.kovidgoyal.net/kitty/build.html you need to run make asan and use ./san-launcher to run kitty |
|
That makes sense. Ideally it would be done by the guy who can reliably elicit a sigsegv rather than me who has to wait a couple weeks for one.. ;) |
|
I've managed to make this crash consistently. I'm using i3, and my process is:
|
|
Doesn't crash for me with those steps, you are scrolling using the mouse wheel, correct? |
|
Note that the fix I just made is speculative, since I cant reproduce the crash. |
kovidgoyal
added a commit
that referenced
this issue
Jun 12, 2019
…e mouse in the alternate screen mode Fixes #1578
|
I can confirm at least on my setup, it seems to be fixed |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
if you scroll downwards and start selecting text upwards, after few scrolls kitty segfaults.
The text was updated successfully, but these errors were encountered: