Bug 1419636 - gvim exits with BadWindow when large visual-blockwise selection is done
Summary: gvim exits with BadWindow when large visual-blockwise selection is done
Keywords:
Status: CLOSED DUPLICATE of bug 1255860
Alias: None
Product: Fedora
Classification: Fedora
Component: vim
Version: 25
Hardware: x86_64
OS: Linux
unspecified
high
Target Milestone: ---
Assignee: Karsten Hopp
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2017-02-06 15:48 UTC by vasilis
Modified: 2017-02-07 17:04 UTC (History)
5 users (show)

Fixed In Version:
Doc Type: If docs needed, set a value
Doc Text:
Clone Of:
Environment:
Last Closed: 2017-02-07 17:04:06 UTC
Type: Bug


Attachments (Terms of Use)
example of a file (2.85 MB, text/plain)
2017-02-07 08:06 UTC, vasilis
no flags Details
strace vim -f (1.10 MB, text/plain)
2017-02-07 10:20 UTC, vasilis
no flags Details


Links
System ID Private Priority Status Summary Last Updated
Github vim vim issues 1023 0 None None None 2017-02-07 15:13:30 UTC

Description vasilis 2017-02-06 15:48:05 UTC
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

Comment 1 Zdenek Dohnal 2017-02-06 17:44:58 UTC
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?

Comment 2 vasilis 2017-02-07 08:06:09 UTC
Created attachment 1248308 [details]
example of a file

Comment 3 vasilis 2017-02-07 08:11:58 UTC
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.

Comment 4 vasilis 2017-02-07 10:20:39 UTC
Created attachment 1248362 [details]
strace vim -f

I don't know if that helps, but it is a strace when the crash happens.

Comment 5 vasilis 2017-02-07 11:27:15 UTC
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

Comment 6 Zdenek Dohnal 2017-02-07 14:59:29 UTC
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.

Comment 7 vasilis 2017-02-07 15:08:50 UTC
How I could debug it?
I was looking in the error code and it claims that it is a XChangeProperty() that is failing

Comment 8 Zdenek Dohnal 2017-02-07 15:13:30 UTC
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 .

Comment 9 vasilis 2017-02-07 15:17:06 UTC
Yes I use the KDE, it should be the same bug

Comment 10 Zdenek Dohnal 2017-02-07 17:04:06 UTC
So I am closing this bug as duplicate of #1255860.

*** This bug has been marked as a duplicate of bug 1255860 ***


Note You need to log in before you can comment on or make changes to this bug.