Bug 1255860 - gvim exits with "BadWindow (invalid window parameter)"
gvim exits with "BadWindow (invalid window parameter)"
Status: NEW
Product: Fedora
Classification: Fedora
Component: vim (Show other bugs)
27
x86_64 Linux
unspecified Severity unspecified
: ---
: ---
Assigned To: Karsten Hopp
Fedora Extras Quality Assurance
: Reopened
: 1419636 (view as bug list)
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2015-08-21 13:41 EDT by Jonathan Wakely
Modified: 2018-05-03 06:04 EDT (History)
7 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2017-08-08 08:09:34 EDT
Type: Bug
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)


External Trackers
Tracker ID Priority Status Summary Last Updated
Github vim/vim/issues/1023 None None None 2017-02-07 12:09 EST

  None (edit)
Description Jonathan Wakely 2015-08-21 13:41:43 EDT
Description of problem:

Vim exits with an X error when trying to highlight a large region of text.

I've only seen it with a particular file (see URL below), not any other files.


Version-Release number of selected component (if applicable):

vim-X11-7.4.640-4.fc22.x86_64
xorg-x11-server-Xorg-1.17.2-2.fc22.x86_64


How reproducible:

Always


Steps to Reproduce:
1. wget https://patch-diff.githubusercontent.com/raw/boostorg/preprocessor/pull/6.patch
2. gvim 6.patch
3. in vim type 5015ggvgg
4. if it hasn't crashed yet hold down j to move down 20 or 30 lines


Actual results:

gvim exits, printing this to the controlling terminal:

BadWindow (invalid Window parameter)
Vim: Got X error
Vim: Finished.
Comment 1 Fedora Update System 2015-09-02 07:46:52 EDT
vim-7.4.827-1.fc21 has been submitted as an update to Fedora 21. https://bodhi.fedoraproject.org/updates/FEDORA-2015-14209
Comment 2 Fedora Update System 2015-09-22 20:21:45 EDT
vim-7.4.827-1.fc21 has been pushed to the Fedora 21 stable repository. If problems still persist, please make note of it in this bug report.
Comment 3 Jonathan Wakely 2015-09-23 06:01:10 EDT
The bug is not fixed in vim-X11-7.4.827-1.fc22.x86_64

Please test it.
Comment 4 Jonathan Wakely 2015-10-08 06:45:07 EDT
The same crash also happens in F23 with vim-X11-7.4.827-1.fc23.x86_64.rpm
Comment 5 Jonathan Wakely 2016-02-16 14:12:01 EST
I have several .tex files that I can't even open, gvim crashes immediately.


tmp$ curl -O https://raw.githubusercontent.com/cplusplus/draft/master/source/containers.tex
  % Total    % Received % Xferd  Average Speed   Time    Time     Time  Current
                                 Dload  Upload   Total   Spent    Left  Speed
100  323k  100  323k    0     0  1274k      0 --:--:-- --:--:-- --:--:-- 1270k
tmp$ gvim containers.tex
tmp$ BadWindow (invalid Window parameter)
Vim: Got X error

(gvim:31313): GLib-WARNING **: g_main_context_prepare() called recursively from within a source's check() or prepare() member.

(gvim:31313): GLib-WARNING **: g_main_context_check() called recursively from within a source's check() or prepare() member.
Vim: Finished.
Comment 6 Jonathan Wakely 2016-03-15 06:57:53 EDT
Do I need to report this upstream?
Comment 7 fszymanski 2016-03-16 14:16:22 EDT
(In reply to Jonathan Wakely from comment #6)
> Do I need to report this upstream?

I'm running F23 with vim-X11-7.4.1570-1.fc23.x86_64.rpm and I cannot reproduce this bug.
Try my build: http://koji.fedoraproject.org/koji/buildinfo?buildID=745712
Comment 8 Jonathan Wakely 2016-03-16 14:26:45 EDT
Same problem with vim-X11-7.4.1570-1.fc23.x86_64.rpm

"gvim -u NONE containers.tex" doesn't exit, so it's something in a plugin or other rc file (but not my personal vimrc, because I get the same problem running as root, with no vimrc customisations).
Comment 9 fszymanski 2016-03-16 14:58:07 EDT
(In reply to Jonathan Wakely from comment #8)
> Same problem with vim-X11-7.4.1570-1.fc23.x86_64.rpm
> 
> "gvim -u NONE containers.tex" doesn't exit, so it's something in a plugin or
> other rc file (but not my personal vimrc, because I get the same problem
> running as root, with no vimrc customisations).

Run gvim in its debugging mode (-D argument) to find out what's wrong.
How-to: http://inlehmansterms.net/2014/10/31/debugging-vim/
Comment 10 Jonathan Wakely 2016-03-17 06:35:05 EDT
Uninstalling vim-latex allows me to open .tex files without it crashing e.g. the file in comment 5. It doesn't help with the patch file in comment 0 though.
Comment 11 Jonathan Wakely 2016-03-17 06:46:28 EDT
Debugging mode doesn't help, because the crash happens after all the files have been read, when the gvim X11 window opens. I can step through every line of every config file, and after it has all been read and the window opens, it exits.

Setting verbose=15 doesn't show me anything that looks useful, but I can attach 75000 lines of verbose output if that would help.
Comment 12 Jonathan Wakely 2016-03-17 06:47:38 EDT
I also did "mv ~/.vim ~/vvv" and tried again, and vim still exits, so it's not my personal vimrc config, but something in /usr that comes with Fedora.
Comment 13 fszymanski 2016-03-17 10:50:01 EDT
(In reply to Jonathan Wakely from comment #12)
> I also did "mv ~/.vim ~/vvv" and tried again, and vim still exits, so it's
> not my personal vimrc config, but something in /usr that comes with Fedora.

I was able to reproduce this bug under KDE (gvim without any plugins or vimrc).
Maybe this error is KDE specific? Under GNOME I don't have any problems.
Comment 14 Jonathan Wakely 2016-03-17 10:54:22 EDT
Possibly, I'm using KDE.
Comment 15 Karsten Hopp 2016-05-24 10:52:57 EDT
Adding kde-sig to CC:, maybe someone there has an idea what's wrong with running gvim under KDE
Comment 16 Rex Dieter 2016-05-24 10:58:22 EDT
Anyone try running vim under gdb so we can see a backtrace of the crash?
Comment 17 Jonathan Wakely 2016-05-24 12:59:35 EDT
$ gdb --quiet  --args gvim -f containers.tex
Reading symbols from gvim...Reading symbols from /usr/lib/debug/usr/bin/gvim.debug...done.
done.
(gdb) br exit
Breakpoint 1 at 0x5f4d0
(gdb) r
Starting program: /usr/bin/gvim -f containers.tex
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/lib64/libthread_db.so.1".

(gvim:10301): Gtk-WARNING **: Theme directory actions/48 of theme breeze has no size field


(gvim:10301): Gtk-WARNING **: Theme directory categories/16 of theme breeze has no size field


(gvim:10301): Gtk-WARNING **: Theme directory categories/22 of theme breeze has no size field


(gvim:10301): Gtk-WARNING **: Theme directory categories/48 of theme breeze has no size field


(gvim:10301): Gtk-WARNING **: Theme directory devices/48 of theme breeze has no size field

[New Thread 0x7fffe5311700 (LWP 10305)]
[New Thread 0x7fffe4b10700 (LWP 10306)]
BadWindow (invalid Window parameter)
Vim: Got X error
Vim: Finished.

Breakpoint 1, __GI_exit (status=status@entry=1) at exit.c:104
104       __run_exit_handlers (status, &__exit_funcs, true);
(gdb) bt
#0  __GI_exit (status=status@entry=1) at exit.c:104
#1  0x00005555556b976b in mch_exit (r=1) at os_unix.c:3288
#2  0x000000000023d763 in ?? ()
#3  0x000055555567b039 in preserve_exit () at misc1.c:9488
#4  0x00005555556b6d60 in x_error_handler (dpy=<optimized out>, error_event=<optimized out>) at os_unix.c:1525
#5  0x00007ffff5d8939d in _XError (dpy=dpy@entry=0x555555a79000, rep=rep@entry=0x5555565be300) at XlibInt.c:1429
#6  0x00007ffff5d86227 in handle_error (dpy=0x555555a79000, err=0x5555565be300, in_XReply=<optimized out>) at xcb_io.c:213
#7  0x00007ffff5d862e5 in handle_response (dpy=dpy@entry=0x555555a79000, response=0x5555565be300, in_XReply=in_XReply@entry=0) at xcb_io.c:325
#8  0x00007ffff5d86ca5 in _XEventsQueued (dpy=dpy@entry=0x555555a79000, mode=mode@entry=2) at xcb_io.c:364
#9  0x00007ffff5d786a7 in XPending (dpy=0x555555a79000) at Pending.c:55
#10 0x00007ffff74ead91 in gdk_check_xpending (display=<optimized out>) at gdkevents-x11.c:159
#11 0x00007ffff74eadfe in gdk_event_check (source=0x555555a92ce0) at gdkevents-x11.c:2400
#12 0x00007ffff675bbb1 in g_main_context_check (context=context@entry=0x555555a92dd0, max_priority=2147483647, fds=fds@entry=0x555555da5d80, n_fds=n_fds@entry=3) at gmain.c:3681
#13 0x00007ffff675c110 in g_main_context_iterate (context=context@entry=0x555555a92dd0, block=block@entry=1, dispatch=dispatch@entry=1, self=<optimized out>) at gmain.c:3837
#14 0x00007ffff675c27c in g_main_context_iteration (context=0x555555a92dd0, context@entry=0x0, may_block=may_block@entry=1) at gmain.c:3901
#15 0x000055555575cc27 in gui_mch_wait_for_chars (wtime=wtime@entry=4000) at gui_gtk_x11.c:6575
#16 0x000055555574c86b in gui_wait_for_chars_or_timer (wtime=4000) at gui.c:2870
#17 0x000055555574e7b9 in gui_wait_for_chars (wtime=wtime@entry=-1) at gui.c:2933
#18 0x000055555573ad80 in ui_inchar (buf=buf@entry=0x555555a31443 <typebuf_init+3> "", maxlen=maxlen@entry=87, wtime=wtime@entry=-1, tb_change_cnt=tb_change_cnt@entry=4) at ui.c:186
#19 0x0000555555648bc3 in inchar (buf=0x555555a31443 <typebuf_init+3> "", maxlen=261, wait_time=-1, tb_change_cnt=4) at getchar.c:3056
#20 0x000055555564ab6f in vgetorpeek (advance=advance@entry=1) at getchar.c:2832
#21 0x000055555564b4ea in vgetc () at getchar.c:1605
#22 0x000055555564b869 in safe_vgetc () at getchar.c:1801
#23 0x000055555569a1d5 in normal_cmd (oap=0x7fffffffd470, toplevel=1) at normal.c:627
#24 0x0000555555792055 in main_loop (cmdwin=0, noexmode=0) at main.c:1359
#25 0x00005555555b884b in main (argc=<optimized out>, argv=<optimized out>) at main.c:1051

Let me know what other info you need, I don't know where else to break other than exit().
Comment 18 Rex Dieter 2016-06-06 07:50:41 EDT
Nothing obvious there I can tell
Comment 19 Fedora End Of Life 2016-07-19 13:36:49 EDT
Fedora 22 changed to end-of-life (EOL) status on 2016-07-19. Fedora 22 is
no longer maintained, which means that it will not receive any further
security or bug fix updates. As a result we are closing this bug.

If you can reproduce this bug against a currently maintained version of
Fedora please feel free to reopen this bug against that version. If you
are unable to reopen this bug, please file a new report against the
current release. If you experience problems, please add a comment to this
bug.

Thank you for reporting this bug and we are sorry it could not be fixed.
Comment 20 Jonathan Wakely 2016-07-19 13:46:13 EDT
Still present in  F23.
Comment 21 Karsten Hopp 2016-10-05 07:06:15 EDT
I'll update vim to vim-8 soon and will also switch from gtk2 to gtk3. I suspect that this error will be gone with that.
Comment 22 Fedora End Of Life 2016-11-24 07:21:30 EST
This message is a reminder that Fedora 23 is nearing its end of life.
Approximately 4 (four) weeks from now Fedora will stop maintaining
and issuing updates for Fedora 23. It is Fedora's policy to close all
bug reports from releases that are no longer maintained. At that time
this bug will be closed as EOL if it remains open with a Fedora  'version'
of '23'.

Package Maintainer: If you wish for this bug to remain open because you
plan to fix it in a currently maintained version, simply change the 'version' 
to a later Fedora version.

Thank you for reporting this issue and we are sorry that we were not 
able to fix it before Fedora 23 is end of life. If you would still like 
to see this bug fixed and are able to reproduce it against a later version 
of Fedora, you are encouraged  change the 'version' to a later Fedora 
version prior this bug is closed as described in the policy above.

Although we aim to fix as many bugs as possible during every release's 
lifetime, sometimes those efforts are overtaken by events. Often a 
more recent Fedora release includes newer upstream software that fixes 
bugs or makes them obsolete.
Comment 23 Jonathan Wakely 2016-11-24 09:20:53 EST
Still happens with F24.
Comment 24 Jonathan Wakely 2016-12-15 04:44:44 EST
Some trial and error revealed that adding this to my vimrc stops gvim from exiting:

let g:tex_fold_enabled=0

Oddly, setting it to 1 also stops it from exiting.
Comment 25 Jonathan Wakely 2016-12-15 05:08:40 EST
Although in F24 opening a TeX file in gvim spews these warnings (whether it crashes or not):

(gvim:20207): Gtk-WARNING **: Allocating size to GtkToolButton 0x55951189aca0 without calling gtk_widget_get_preferred_width/height(). How does the code know the size to allocate?

(gvim:20207): Gtk-WARNING **: Allocating size to GtkSeparatorToolItem 0x55951189b3a0 without calling gtk_widget_get_preferred_width/height(). How does the code know the size to allocate?

(gvim:20207): Gtk-WARNING **: Allocating size to GtkToolButton 0x55951189ae70 without calling gtk_widget_get_preferred_width/height(). How does the code know the size to allocate?

(gvim:20207): Gtk-WARNING **: Allocating size to GtkToolButton 0x55951189d1f0 without calling gtk_widget_get_preferred_width/height(). How does the code know the size to allocate?

(gvim:20207): Gtk-WARNING **: Allocating size to GtkToolButton 0x55951189d3c0 without calling gtk_widget_get_preferred_width/height(). How does the code know the size to allocate?

(gvim:20207): Gtk-WARNING **: Allocating size to GtkSeparatorToolItem 0x55951189ba60 without calling gtk_widget_get_preferred_width/height(). How does the code know the size to allocate?

(gvim:20207): Gtk-WARNING **: Allocating size to GtkToolButton 0x55951189d590 without calling gtk_widget_get_preferred_width/height(). How does the code know the size to allocate?
Comment 26 Zdenek Dohnal 2017-02-07 12:04:06 EST
*** Bug 1419636 has been marked as a duplicate of this bug. ***
Comment 27 Rex Dieter 2017-02-07 12:09:39 EST
Adding reference to upstream issue from dup'd bug
Comment 28 Jonathan Wakely 2017-02-07 12:16:02 EST
(In reply to Jonathan Wakely from comment #25)
> Although in F24 opening a TeX file in gvim spews these warnings (whether it
> crashes or not):
> 
> (gvim:20207): Gtk-WARNING **: Allocating size to GtkToolButton
> 0x55951189aca0 without calling gtk_widget_get_preferred_width/height(). How
> does the code know the size to allocate?

This is because the gvim plugins for tex resize the window to fit all the extra menus. These warnings are unrelated to the "BadWindow" exit bug, so I reported them as Bug 1419982.
Comment 29 vasilis 2017-02-09 03:01:56 EST
Same problem here with FC25 and vim 8.0.238, KDE 5.8.5.
I've tried tried settings the g:tex_fold_enabled without succerss
Comment 30 Jonathan Wakely 2017-06-13 11:21:33 EDT
This seems to be related to Klipper, which would explain why it only happens under KDE.

As https://github.com/vim/vim/issues/1023#issuecomment-307426892 says, if you change the Klipper settings to "Ignore the selection" then gvim doesn't crash when selecting large regions of text.
Comment 31 Jonathan Wakely 2017-06-13 11:29:56 EDT
Updated steps to reproduce:

- run KDE and the Klipper applet
- configure clipboard applet and uncheck "Ignore selection"
- wget https://raw.githubusercontent.com/cplusplus/draft/2f118eb5c2d546aaf830f92b262039083e40576f/source/utilities.tex
- gvim -u NONE utilities.tex
- in the gvim window type "ggvG"
Comment 32 Fedora End Of Life 2017-07-25 15:11:06 EDT
This message is a reminder that Fedora 24 is nearing its end of life.
Approximately 2 (two) weeks from now Fedora will stop maintaining
and issuing updates for Fedora 24. It is Fedora's policy to close all
bug reports from releases that are no longer maintained. At that time
this bug will be closed as EOL if it remains open with a Fedora  'version'
of '24'.

Package Maintainer: If you wish for this bug to remain open because you
plan to fix it in a currently maintained version, simply change the 'version'
to a later Fedora version.

Thank you for reporting this issue and we are sorry that we were not
able to fix it before Fedora 24 is end of life. If you would still like
to see this bug fixed and are able to reproduce it against a later version
of Fedora, you are encouraged  change the 'version' to a later Fedora
version prior this bug is closed as described in the policy above.

Although we aim to fix as many bugs as possible during every release's
lifetime, sometimes those efforts are overtaken by events. Often a
more recent Fedora release includes newer upstream software that fixes
bugs or makes them obsolete.
Comment 33 Fedora End Of Life 2017-08-08 08:09:34 EDT
Fedora 24 changed to end-of-life (EOL) status on 2017-08-08. Fedora 24 is
no longer maintained, which means that it will not receive any further
security or bug fix updates. As a result we are closing this bug.

If you can reproduce this bug against a currently maintained version of
Fedora please feel free to reopen this bug against that version. If you
are unable to reopen this bug, please file a new report against the
current release. If you experience problems, please add a comment to this
bug.

Thank you for reporting this bug and we are sorry it could not be fixed.
Comment 34 Jonathan Wakely 2017-08-09 13:09:17 EDT
Oh how I hate the EOL bot.

This still happens with F26.
Comment 35 Jonathan Wakely 2017-08-09 13:20:09 EDT
The steps in Comment 31 are still enough to reproduce this. Make sure to "Apply" after unchecking the "Ignore selection" option in the kilpper config.
Comment 36 Pawel Veselov 2018-04-12 10:19:17 EDT
This is alive and well and F27 as well.
The evil here is klipper, this is not really a gvim problem, except that somehow gvim gets the XError when sending text to the clipboard, where others may somehow survive or not receive it. Or it's not as easy to amass a large enough selection to trigger the issue.

It's worse than that, if you try using clipper after selecting so much text, it hangs plasmashell. It can wreck your entire X, i.e. I managed to hang my gnome terminal dead, by trying to right-click on it while plasmashell was hung.

It should be considered that this in essence makes klipper unusable, and turns it into a time bomb, until you just happen to select something large enough into your clipboard. You want it disabled, so that you just don't run into this, which makes it moot.
Comment 37 Jonathan Wakely 2018-04-12 11:14:52 EDT
Thanks for the analysis. How can I disable klipper?
Comment 38 Pawel Veselov 2018-04-12 11:22:38 EDT
If you don't care for it ever running, blast /usr/share/plasma/plasmoids/org.kde.plasma.clipboard directory into /dev/null. You may have to redo it everytime updates for plasmashell are installed. There is (and rather old) discussion on this at https://forum.kde.org/viewtopic.php?f=66&t=128086
Comment 39 Rex Dieter 2018-04-12 11:38:31 EDT
Not necessary.

Right click ^ in plasma system tray => system tray settings
under general => extra items, check/uncheck the applets you desire

In this case, uncheck "clipboard"
Comment 40 Pawel Veselov 2018-04-12 12:48:58 EDT
@Rex according to that KDE forum, that just hides it, doesn't stop klipper code from running and grabbing the cut buffers.
To think of it, I'm not convinced that removing the plasmoid directory stops it either. IMHO, setting "ignore text" and then hiding it (either way) is at least enough to not run into the problematic behavior.
Comment 41 Fedora End Of Life 2018-05-03 04:48:09 EDT
This message is a reminder that Fedora 26 is nearing its end of life.
Approximately 4 (four) weeks from now Fedora will stop maintaining
and issuing updates for Fedora 26. It is Fedora's policy to close all
bug reports from releases that are no longer maintained. At that time
this bug will be closed as EOL if it remains open with a Fedora  'version'
of '26'.

Package Maintainer: If you wish for this bug to remain open because you
plan to fix it in a currently maintained version, simply change the 'version'
to a later Fedora version.

Thank you for reporting this issue and we are sorry that we were not
able to fix it before Fedora 26 is end of life. If you would still like
to see this bug fixed and are able to reproduce it against a later version
of Fedora, you are encouraged  change the 'version' to a later Fedora
version prior this bug is closed as described in the policy above.

Although we aim to fix as many bugs as possible during every release's
lifetime, sometimes those efforts are overtaken by events. Often a
more recent Fedora release includes newer upstream software that fixes
bugs or makes them obsolete.

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