1

NOTE: This underlying problem was solved by an update of Cygwin packages and re-install of vim. However, the question of how to trace errors in shelling out remains, so answers along that front would be appreciated.

I use Cygwin's 64-bit installation on Windows 10 Pro (64-bit), including X-windows and vim/gvim. In all the installs I've done this year, I get the following message:

** (gvim:2221): WARNING **: Error retrieving accessibility bus address: org.free desktop.DBus.Error.NoReply: Message recipient disconnected from message bus with out replying

I've successfully ignored it until now. On a brand new installation yesterday, however, when I shell out from gvim, it freezes. The task manager shows 20% CPU usage due to gvim, and I assume that its fully using 1 of 4 cores (i5-8365U). This is observed from a non-administrator account. Oddly, if I do the same thing from an administrator account, it still freezes, but there is no CPU usage. I make sure that I remove the following X-windows files from the non-administrator account before switching to test from the administrator account:

rm -rf ~/.serverauth.* /tmp/.X0-lock /tmp/.X11-unix /var/log/xwin/XWin.0.log

Issuing kill from a bash shell doesn't banish the window, and neither does ending the task from Task Manager (with and without elevated privileges). If I exit the xterm from which gvim was issued, however, the unresponsive gvim process and window goes away.

I don't like doing this, however, as the current X-windows installation doesn't give me an option to launch a new xterm. I need to shut down X-windows, then start it again.

I've included vim/gvim in the question because I'm not sure where the problem occurs. The problem only shows with I use gvim, but I can't necessarily blame gvim. This is because I have one vimrc for both, and it checks whether it is being run from Windows compilation or a cygwin compilation, and also checks whether it is vim or gvim. Some of the code differs depending on these checks. Having everything in one file is a net benefit, however, because I have a lot of common setup code. It means, however, that the cause of the crash could very well be due to different control flow in my vimrc rather than Cygwin's gvim.

Is there a way to turn on verbose messaging so that I can see what is happening when I shell out?

Is there another way to trace the events that might cause this crash?

I usually shell out in one of 2 ways:

1. In normal mode, double-bang (!!) followed by a bash command, e.g., !!ls

2. In the : command line, starting with a bang (!), optionally preceded by a line range.

Attempted Troubleshooting

  • :set verbose doesn't help, because I'm shelling out rather than calling vim scripts

  • If I start gvim -u NONE -U NONE, then :scriptnames shows only following and attempts to shell out no longer freeze gvim:

    1: /usr/share/vim/vim82/menu.vim
    2: /usr/share/vim/vim82/autoload/paste.vim

  • However, a normal mode like !!ls doesn't import the results of the ls command either. It merely results in the message Command terminated. It would be nice to be able to trace the cause of this.

  • If I right-click the X-windows server on the system tray, I have to option of view the log file /var/log/xwin/XWin.0.log (Annex below)....

Annex: /var/log/xwin/XWin.0.log

Welcome to the XWin X Server
Vendor: The Cygwin/X Project
Release: 1.20.5.0
OS: CYGWIN_NT-10.0-18362 ___-____-___-__ 3.1.5-340.x86_64 2020-06-01 08:59 UTC x86_64
OS: Windows 10  [Windows NT 10.0 build 18362] (Win64)
Package: version 1.20.5-3 built 2019-09-06

XWin was started with the following command line:

/usr/bin/XWin :0 -multiwindow -auth 
 /home/User.Name/.serverauth.1210 

ddxProcessArgument - Initializing default screens
winInitializeScreenDefaults - primary monitor w 1920 h 1080
winInitializeScreenDefaults - native DPI x 144 y 144
[   845.234] (II) xorg.conf is not supported
[   845.234] (II) See http://x.cygwin.com/docs/faq/cygwin-x-faq.html for more information
[   845.234] LoadPreferences: /home/User.Name/.XWinrc not found
[   845.234] LoadPreferences: Loading /etc/X11/system.XWinrc
[   845.250] LoadPreferences: Done parsing the configuration file...
[   845.250] winDetectSupportedEngines - RemoteSession: no
[   845.296] winDetectSupportedEngines - DirectDraw4 installed, allowing ShadowDDNL
[   845.296] winDetectSupportedEngines - Returning, supported engines 00000005
[   845.296] winSetEngine - Multi Window or Rootless => ShadowGDI
[   845.296] winScreenInit - Using Windows display depth of 32 bits per pixel
[   845.359] winAllocateFBShadowGDI - Creating DIB with width: 1920 height: 1080 depth: 32
[   845.359] winFinishScreenInitFB - Masks: 00ff0000 0000ff00 000000ff
[   845.359] winInitVisualsShadowGDI - Masks 00ff0000 0000ff00 000000ff BPRGB 8 d 24 bpp 32
[   845.359] MIT-SHM extension disabled due to lack of kernel support
[   845.359] XFree86-Bigfont extension local-client optimization disabled due to lack of shared memory support in the kernel
[   845.375] glWinSelectGLimplementation: Loaded 'cygnativeGLthunk.dll'
[   845.453] (II) AIGLX: Testing pixelFormatIndex 1
[   845.531] GL_VERSION:     4.6.0 - Build 27.20.100.8190
[   845.531] GL_VENDOR:      Intel
[   845.531] GL_RENDERER:    Intel(R) UHD Graphics 620
[   845.531] (II) GLX: enabled GLX_SGI_make_current_read
[   845.531] (II) GLX: enabled GLX_SGI_swap_control
[   845.546] (II) GLX: enabled GLX_MESA_swap_control
[   845.546] (II) GLX: enabled GLX_SGIX_pbuffer
[   845.546] (II) GLX: enabled GLX_ARB_multisample
[   845.546] (II) GLX: enabled GLX_SGIS_multisample
[   845.546] (II) GLX: enabled GLX_ARB_fbconfig_float
[   845.546] (II) GLX: enabled GLX_EXT_fbconfig_packed_float
[   845.546] (II) GLX: enabled GLX_ARB_create_context
[   845.546] (II) GLX: enabled GLX_ARB_create_context_profile
[   845.546] (II) GLX: enabled GLX_ARB_create_context_robustness
[   845.546] (II) GLX: enabled GLX_EXT_create_context_es2_profile
[   845.546] (II) GLX: enabled GLX_ARB_framebuffer_sRGB
[   845.546] (II) AIGLX: enabled GLX_MESA_copy_sub_buffer
[   845.546] (II) 108 pixel formats reported by wglGetPixelFormatAttribivARB
[   845.562] (II) 72 fbConfigs
[   845.562] (II) ignored pixel formats: 0 not OpenGL, 0 unknown pixel type, 36 unaccelerated
[   845.562] (II) GLX: Initialized Win32 native WGL GL provider for screen 0
[   846.203] winPointerWarpCursor - Discarding first warp: 960 540
[   846.203] (--) 5 mouse buttons found
[   846.203] (--) Setting autorepeat to delay=500, rate=31
[   846.203] (--) Windows keyboard layout: "00000409" (00000409) "US", type 7
[   846.203] (--) Found matching XKB configuration "English (USA)"
[   846.203] (--) Model = "pc105" Layout = "us" Variant = "none" Options = "none"
[   846.203] Rules = "base" Model = "pc105" Layout = "us" Variant = "none" Options = "none"
[   846.203] [   846.203] winInitMultiWindowWM - DISPLAY=:0.0
winMultiWindowXMsgProc - DISPLAY=:0.0
[   846.421] winInitMultiWindowWM - xcb_connect () returned and successfully opened the display.
[   846.437] winProcEstablishConnection - winInitClipboard returned.
[   846.437] winClipboardThreadProc - DISPLAY=:0.0
[   846.437] winMultiWindowXMsgProc - xcb_connect() returned and successfully opened the display.
[   846.437] winClipboardProc - xcb_connect () returned and successfully opened the display.
[   846.437] Using Composite redirection
[   851.250] SetupSysMenu: GetSystemMenu() failed for HWND 0x5048a
[   992.875] OS has icon alpha channel support: yes
[  1096.187] executing 'xterm -title $XWINLOGFILE -e less +F $XWINLOGFILE', pid 1282
[  1101.500] SetupSysMenu: GetSystemMenu() failed for HWND 0x80752
[  1142.750] executing 'xterm -title $XWINLOGFILE -e less +F $XWINLOGFILE', pid 1284
[  1153.953] SetupSysMenu: GetSystemMenu() failed for HWND 0x50730
[  1201.625] executing 'xterm -title $XWINLOGFILE -e less +F $XWINLOGFILE', pid 1286
Improve this question
3
  • 2
    try setting the verbose option. I believe if you set it to 5 or higher, vim will tell you what shell command it actually runs.
    – Christian Brabandt
    Aug 14, 2020 at 6:14
  • 1
    Thanks, Christian! That works. It gave Calling shell to execute: "(ls) < /tmp/vrSTxrs/32>/tmp/vrSTxrs/33 2>&1". Did you want to post that as the answer? BTW, I'm still using your cursor highlighting from years back!
    – user2153235
    Aug 14, 2020 at 14:06
  • 1
    @user2153235 Feel free to self answer the question with the details of what worked for you...
    – filbranden ♦
    Aug 16, 2020 at 18:51

1 Answer 1

Reset to default
1

Contrary to what I inferred from a too-quick perusal of the help, setting the verbose option to 5 lets me see the command that is issued by vim when shelling out. By then, however, I had already banished the problem by upgrading all Cygwin packages and re-installing vim. So I will probably never really find out what the pathology was in shelling out.

Thanks to Christian Brabandt for correcting my misconception that verbose wouldn't help.

Improve this answer

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge that you have read and understand our privacy policy and code of conduct.

Not the answer you're looking for? Browse other questions tagged or ask your own question.