Bug 1419636
Summary: | gvim exits with BadWindow when large visual-blockwise selection is done | ||||||||
---|---|---|---|---|---|---|---|---|---|
Product: | [Fedora] Fedora | Reporter: | vasilis <vasilis.vlachoudis> | ||||||
Component: | vim | Assignee: | Karsten Hopp <karsten> | ||||||
Status: | CLOSED DUPLICATE | QA Contact: | Fedora Extras Quality Assurance <extras-qa> | ||||||
Severity: | high | Docs Contact: | |||||||
Priority: | unspecified | ||||||||
Version: | 25 | CC: | gchamoul, karsten, moshima.web, vasilis.vlachoudis, zdohnal | ||||||
Target Milestone: | --- | ||||||||
Target Release: | --- | ||||||||
Hardware: | x86_64 | ||||||||
OS: | Linux | ||||||||
Whiteboard: | |||||||||
Fixed In Version: | Doc Type: | If docs needed, set a value | |||||||
Doc Text: | Story Points: | --- | |||||||
Clone Of: | Environment: | ||||||||
Last Closed: | 2017-02-07 17:04:06 UTC | Type: | Bug | ||||||
Regression: | --- | Mount Type: | --- | ||||||
Documentation: | --- | CRM: | |||||||
Verified Versions: | Category: | --- | |||||||
oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |||||||
Cloudforms Team: | --- | Target Upstream Version: | |||||||
Embargoed: | |||||||||
Attachments: |
|
Description
vasilis
2017-02-06 15:48:05 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? 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 *** |