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.
vim-7.4.827-1.fc21 has been submitted as an update to Fedora 21. https://bodhi.fedoraproject.org/updates/FEDORA-2015-14209
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.
The bug is not fixed in vim-X11-7.4.827-1.fc22.x86_64 Please test it.
The same crash also happens in F23 with vim-X11-7.4.827-1.fc23.x86_64.rpm
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.
Do I need to report this upstream?
(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
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).
(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/
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.
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.
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.
(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.
Possibly, I'm using KDE.
Adding kde-sig to CC:, maybe someone there has an idea what's wrong with running gvim under KDE
Anyone try running vim under gdb so we can see a backtrace of the crash?
$ 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().
Nothing obvious there I can tell
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.
Still present in F23.
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.
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.
Still happens with F24.
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.
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?
*** Bug 1419636 has been marked as a duplicate of this bug. ***
Adding reference to upstream issue from dup'd bug
(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.
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
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.
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"
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.
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.
Oh how I hate the EOL bot. This still happens with F26.
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.
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.
Thanks for the analysis. How can I disable klipper?
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
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"
@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.
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.
This message is a reminder that Fedora 27 is nearing its end of life. On 2018-Nov-30 Fedora will stop maintaining and issuing updates for Fedora 27. 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 '27'. 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 27 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.
Confirmed in F29 using the file in comment 5. Enter visual mode, select the entire file, then hit 'y' to crash Vim. Should this be reassigned to Klipper?
We can try it - Do you know the component? Because klipper isn't the right name in the bugzilla.
/usr/bin/klipper belongs to plasma-workspace
Thanks, Jon!
This message is a reminder that Fedora 29 is nearing its end of life. Fedora will stop maintaining and issuing updates for Fedora 29 on 2019-11-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 '29'. 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 29 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.
Still present in F31.
Specifically, the steps in comment 31 still kill gvim in F31. Checking the "Ignore selection" checkbox in the clipboard config still prevents the error (but means the X11 selection is ignored by klipper, which seems fine to me).
"Ignore selection" doesn't help me, at least not for all files. It can be reproduced with xclip. [vps@phoenix]/tmp$ cat /tmp/test |xclip -selection clipboard [vps@phoenix]/tmp$ X Error of failed request: BadWindow (invalid Window parameter) Major opcode of failed request: 18 (X_ChangeProperty) Resource id in failed request: 0x2400418 Serial number of failed request: 23 Current serial number in output stream: 23 I'm attached the gzipped file. This is with "Ignore Selection" turned on in Clipboard.
Created attachment 1639027 [details] test data to replicate the problem
This message is a reminder that Fedora 31 is nearing its end of life. Fedora will stop maintaining and issuing updates for Fedora 31 on 2020-11-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 '31'. 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 31 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.
Fedora 31 changed to end-of-life (EOL) status on 2020-11-24. Fedora 31 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.
The steps in comment 31 no longer crash gvim in F32, instead it prints: (gvim:1867620): GLib-WARNING **: 17:12:07.236: g_main_context_prepare() called recursively from within a source's check() or prepare() member. (gvim:1867620): GLib-WARNING **: 17:12:07.236: g_main_context_check() called recursively from within a source's check() or prepare() member.
(In reply to Jonathan Wakely from comment #54) > The steps in comment 31 no longer crash gvim in F32, instead it prints: > > (gvim:1867620): GLib-WARNING **: 17:12:07.236: g_main_context_prepare() > called recursively from within a source's check() or prepare() member. > > (gvim:1867620): GLib-WARNING **: 17:12:07.236: g_main_context_check() called > recursively from within a source's check() or prepare() member. FWIW I don't see those warnings in F38