Hide Forgot
Description of problem: gvim exits with $ gvim RTPLANbeam_RTPLAN_0.inp $ BadWindow (invalid Window parameter) Vim: Got X error Vim: Finished. when I start a blockwise selection Ctrl-v (actually it is mapped to Ctrl-q) on a file that contains several thousands of lines Version-Release number of selected component (if applicable): vim-X11-8.0.238-1.fc25.x86_64 How reproducible: Every time Steps to Reproduce: 1. Open a large file +10k lines 2. Go to the top gg and start visual selection Ctrl-v 3. Go to the end of the file G 4. Start moving the cursor on the right to enlarge selection 5. after a while it crashes Additional info: It started after I updraded my FC23 to FC25 and vim went from 7.x to 8.x
Hi vasilis, thank you for contacting us. I tried to reproduce your issue by your steps (I created file with 100k lines, each line has 634 chars), but no crash happened. Would you mind sending that file, if it doesn't contain some private info?
Created attachment 1248308 [details] example of a file
Thanks Zdenek for looking into this. I've just uploaded one file. Actually the file is not important, any big file will do it for me and it is regular. An additional information, I've just tried today to open the same file remotely over ssh connection and I didn't had any crash. Could it be that it is graphics card related? I have nvidia Quadro K2200 card with the latest nvidia driver 375.26.
Created attachment 1248362 [details] strace vim -f I don't know if that helps, but it is a strace when the crash happens.
I've to open in gdb with the debuginfo and set a breakpoint in the XGetErrorText() and I got the following backtrace #0 0x00005555556b8dd4 in x_error_handler (dpy=0x555555a7a000, error_event=0x7fffffffc930) at os_unix.c:1577 #1 0x00007ffff55afddd in _XError (dpy=dpy@entry=0x555555a7a000, rep=rep@entry=0x5555565cbc00) at XlibInt.c:1434 #2 0x00007ffff55acd07 in handle_error (dpy=0x555555a7a000, err=0x5555565cbc00, in_XReply=<optimized out>) at xcb_io.c:199 #3 0x00007ffff55acdc5 in handle_response (dpy=0x555555a7a000, response=0x5555565cbc00, in_XReply=<optimized out>) at xcb_io.c:311 #4 0x00007ffff55ad6c5 in _XEventsQueued (dpy=dpy@entry=0x555555a7a000, mode=mode@entry=2) at xcb_io.c:350 #5 0x00007ffff559f397 in XPending (dpy=0x555555a7a000) at Pending.c:55 #6 0x00007ffff723c641 in gdk_check_xpending (display=<optimized out>) at gdkeventsource.c:269 #7 0x00007ffff723c641 in gdk_event_source_check (source=0x555555a61c40) at gdkeventsource.c:306 #8 0x00007ffff5f80ba9 in g_main_context_check (context=context@entry=0x555555aabe20, max_priority=2147483647, fds=fds@entry=0x5555561e0de0, n_fds=n_fds@entry=4) at gmain.c:3762 #9 0x00007ffff5f810f4 in g_main_context_iterate (context=context@entry=0x555555aabe20, block=block@entry=1, dispatch=dispatch@entry=1, self=<optimized out>) at gmain.c:3926 #10 0x00007ffff5f8126c in g_main_context_iteration (context=0x555555aabe20, context@entry=0x0, may_block=may_block@entry=1) at gmain.c:3990 #11 0x000055555576949c in gui_mch_wait_for_chars (wtime=wtime@entry=4000) at gui_gtk_x11.c:6656 #12 0x0000555555758d3b in gui_wait_for_chars_or_timer (wtime=4000) at gui.c:2877 #13 0x000055555575ac81 in gui_wait_for_chars (wtime=wtime@entry=-1) at gui.c:2940 #14 0x00005555557407bd in ui_inchar (buf=buf@entry=0x555555a4a2f1 <typebuf_init+17> "", maxlen=maxlen@entry=82, wtime=wtime@entry=-1, tb_change_cnt=tb_change_cnt@entry=18) at ui.c:186 #15 0x000055555564eb64 in inchar (buf=0x555555a4a2f1 <typebuf_init+17> "", maxlen=247, wait_time=-1, tb_change_cnt=18) at getchar.c:3062 #16 0x0000555555650a7c in vgetorpeek (advance=advance@entry=1) at getchar.c:2838 #17 0x0000555555651490 in vgetc () at getchar.c:1605 #18 0x0000555555651919 in safe_vgetc () at getchar.c:1801 #19 0x000055555569b720 in normal_cmd (oap=0x7fffffffcfb0, toplevel=1) at normal.c:628 #20 0x00005555557a1125 in main_loop (cmdwin=0, noexmode=0) at main.c:1311 #21 0x00005555557a22a0 in vim_main2 () at main.c:877 #22 0x00005555555b9021 in main (argc=<optimized out>, argv=<optimized out>) at main.c:415
I couldn't reproduce it even with your file (I hope I am doing it correctly - gg, ctrl+v, G and after that moving cursor to right to expand marked area), so I think it is probably issue with your graphic card. The most suspicious line from strace is this: writev(3, [{iov_base="\22\0\0\0\7\0\1\0\232\0\0\2m\1\0\0\251\1\0\0\10\377\2\0\0\0\4\0", iov_len=28}, {iov_base="* *******\n* 1)parti\n* 4)momen\n* "..., iov_len=262144}, {iov_base="", iov_len=0}], 3) = 262172 Other writev calls have iov_base pointer set to NULL. It seems that pointer points to big data and after that writev gvim falls.
How I could debug it? I was looking in the error code and it claims that it is a XChangeProperty() that is failing
vasilis, do you have KDE as desktop environment? If you do, I think you are experiencing this upstream bug https://github.com/vim/vim/issues/1023 .
Yes I use the KDE, it should be the same bug
So I am closing this bug as duplicate of #1255860. *** This bug has been marked as a duplicate of bug 1255860 ***