Re: startx with different displays
Back to my original problem... I tried startxwin (as suggested by a colleague) and this one accepts to start XWin on DISPLAY :0 Are all my problems related to startx? I can see that defaulting to the highest display found in /tmp/.X* seems to comes from it... Does anybody use startx with success? Marc -- View this message in context: http://old.nabble.com/startx-with-different-displays-tp33702991p33745960.html Sent from the cygwin-xfree mailing list archive at Nabble.com. -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://x.cygwin.com/docs/ FAQ: http://x.cygwin.com/docs/faq/
Re: dbus-launch --exit-with-session fails when run from .startxwinrc
On 24/04/2012 14:50, Ken Brown wrote: On 4/16/2012 9:50 AM, Ken Brown wrote: On 4/16/2012 9:44 AM, Ken Brown wrote: The following problem occurs on my 64-bit Windows 7 system but not on my XP system. I start the X server using the Start Menu shortcut [modified to add -emulate3buttons] and a .startxwinrc with the following contents: eval `dbus-launch --sh-syntax --exit-with-session` xterm Running ps in the resulting xterm window shows no dbus-launch or dbus-daemon process. But I can give the same dbus-launch command in the xterm window, and the processes start as expected. I'm attaching cygcheck output and the XWin log. My hope in reporting this is that the problem I'm seeing (and the difference between XP and Win7) is somehow related to the emacs problem I've been trying to solve: http://cygwin.com/ml/cygwin-xfree/2012-04/msg00048.html Ken P.S. You'll see in the cygcheck output that I'm running a Cygwin snapshot; but nothing changes if I revert to cygwin-1.7.13-1. I forgot to say that if I remove --exit-with-session from the command line in my .startxwinrc, then a dbus-daemon process does start. I tried modifying the X server shortcut to read C:\cygwin\bin\run.exe /usr/bin/bash.exe -l -c '/usr/bin/startxwin.exe /var/log/xwin/startxwin.log 21' as suggested in a different thread, but that provides no information. The resulting startxwin.log is virtually identical (with minor differences) to XWin.0.log. In particular, there's no indication of what's happening when .startxwinrc is processed. There's no output because ~/.startxwinrc generates no output. For starters, it would really be helpful if someone could try to reproduce my problem on a 64-bit Windows 7 system. At the moment, I don't even know if there is a bug somewhere or simply a problem with my own system. Here's the recipe: 1. Create a .startxwinrc file with the following contents: eval `dbus-launch --sh-syntax --exit-with-session` xterm 2. Start the X server using the Start Menu shortcut. 3. In the resulting xterm window, give the ps command. If things are working right, the output from ps should show a dbus-launch process and a dbus-daemon process. These processes do appear on my XP system but not on my Windows 7 system. FWIW, it works on XP for me as well. I tried with the following ~/.startxwinrc: eval `dbus-launch --sh-syntax --exit-with-session | tee /dev/stderr` xterm ... which at least lets you see the pid of the dbus-daemon that is started. I'm not sure if --exit-with-session is correct with startxwin, since the startxwin process will not linger after it has started ~/.startxwinrc, and I don't know if stdin will remain open after it (and the process tree above it waiting for it) exits. I have this vague recollection that 'run' has to do different things on XP and W7, which might account for the different behaviour? -- Jon TURNEY Volunteer Cygwin/X X Server maintainer -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://x.cygwin.com/docs/ FAQ: http://x.cygwin.com/docs/faq/
Re: dbus-launch --exit-with-session fails when run from .startxwinrc
On 4/25/2012 12:21 PM, Jon TURNEY wrote: On 24/04/2012 14:50, Ken Brown wrote: On 4/16/2012 9:50 AM, Ken Brown wrote: On 4/16/2012 9:44 AM, Ken Brown wrote: The following problem occurs on my 64-bit Windows 7 system but not on my XP system. I start the X server using the Start Menu shortcut [modified to add -emulate3buttons] and a .startxwinrc with the following contents: eval `dbus-launch --sh-syntax --exit-with-session` xterm Running ps in the resulting xterm window shows no dbus-launch or dbus-daemon process. But I can give the same dbus-launch command in the xterm window, and the processes start as expected. I'm attaching cygcheck output and the XWin log. My hope in reporting this is that the problem I'm seeing (and the difference between XP and Win7) is somehow related to the emacs problem I've been trying to solve: http://cygwin.com/ml/cygwin-xfree/2012-04/msg00048.html Ken P.S. You'll see in the cygcheck output that I'm running a Cygwin snapshot; but nothing changes if I revert to cygwin-1.7.13-1. I forgot to say that if I remove --exit-with-session from the command line in my .startxwinrc, then a dbus-daemon process does start. I tried modifying the X server shortcut to read C:\cygwin\bin\run.exe /usr/bin/bash.exe -l -c '/usr/bin/startxwin.exe /var/log/xwin/startxwin.log 21' as suggested in a different thread, but that provides no information. The resulting startxwin.log is virtually identical (with minor differences) to XWin.0.log. In particular, there's no indication of what's happening when .startxwinrc is processed. There's no output because ~/.startxwinrc generates no output. For starters, it would really be helpful if someone could try to reproduce my problem on a 64-bit Windows 7 system. At the moment, I don't even know if there is a bug somewhere or simply a problem with my own system. Here's the recipe: 1. Create a .startxwinrc file with the following contents: eval `dbus-launch --sh-syntax --exit-with-session` xterm 2. Start the X server using the Start Menu shortcut. 3. In the resulting xterm window, give the ps command. If things are working right, the output from ps should show a dbus-launch process and a dbus-daemon process. These processes do appear on my XP system but not on my Windows 7 system. FWIW, it works on XP for me as well. I tried with the following ~/.startxwinrc: eval `dbus-launch --sh-syntax --exit-with-session | tee /dev/stderr` xterm ... which at least lets you see the pid of the dbus-daemon that is started. I'm not sure if --exit-with-session is correct with startxwin, since the startxwin process will not linger after it has started ~/.startxwinrc, and I don't know if stdin will remain open after it (and the process tree above it waiting for it) exits. I have this vague recollection that 'run' has to do different things on XP and W7, which might account for the different behaviour? Ah, that must be it. On XP, presumably because of the way 'run' behaves, the sh process that runs .startxwinrc hangs around, so the dbus processes keep running. If I run startxwin from a terminal instead of via the shortcut (i.e., without using 'run'), I get the same behavior on XP as on W7. Thanks. Ken -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://x.cygwin.com/docs/ FAQ: http://x.cygwin.com/docs/faq/
Fatal Error (Segmentation Fault) only while viewing the LVM GUI
I think I may have found a bug. I am connecting to a remote Linux server from my Windows desktop and attempting to use some of the GUI tools on the remote server. The xclock GUI displays fine. The Oracle dbca GUI displays fine. The LVM system-config-lvm GUI displays and works fine, but cygwin generates a fatal error window due to a segmentation fault. Please see below: airs0cld@2UA0070JZB ~ $ ssh -Y root@aorahdev root@aorahdev's password: Warning: No xauth data; using fake authentication data for X11 forwarding. Last login: Wed Apr 25 14:04:58 2012 from 2ua0070jzb.nysdoi.int The following command displays the GUI without any issue: [root@aorahdev ~]# xclock The following command displays the GUI without any issue: [root@aorahdev ~]# . oraenv ORACLE_SID = [root] ? oradshr [root@aorahdev ~]# dbca Warning: Cannot convert string -bh-lucida-medium-r-normal-sans-*-140-*-*-p-*-iso8859-1 to type FontStruct The following command displays the GUI, but reports a fatal error: [root@aorahdev ~]# system-config-lvm The contents of the XWin.0.log file are as follows: Welcome to the XWin X Server Vendor: The Cygwin/X Project Release: 1.12.0.0 OS: Windows XP Service Pack 3 [Windows NT 5.1 build 2600] (Win32) Package: version 1.12.0-4 built 2012-04-17 XWin was started with the following command line: X :0 -multiwindow ddxProcessArgument - Initializing default screens winInitializeScreenDefaults - primary monitor w 1680 h 1050 winInitializeScreenDefaults - native DPI x 96 y 96 _XSERVTransSocketOpenCOTSServer: Unable to open socket for inet6 _XSERVTransOpen: transport open failed for inet6/2UA0070JZB:0 _XSERVTransMakeAllCOTSServerListeners: failed to open listener for inet6 [ 64084.203] (II) xorg.conf is not supported (II) xorg.conf is not supported [ 64084.203] (II) See http://x.cygwin.com/docs/faq/cygwin-x-faq.html for more information (II) See http://x.cygwin.com/docs/faq/cygwin-x-faq.html for more information [ 64084.203] LoadPreferences: /home/airs0cld/.XWinrc not found LoadPreferences: /home/airs0cld/.XWinrc not found [ 64084.203] LoadPreferences: Loading /etc/X11/system.XWinrc LoadPreferences: Loading /etc/X11/system.XWinrc [ 64084.203] LoadPreferences: Done parsing the configuration file... LoadPreferences: Done parsing the configuration file... [ 64084.203] winDetectSupportedEngines - DirectDraw installed, allowing ShadowDD winDetectSupportedEngines - DirectDraw installed, allowing ShadowDD [ 64084.203] winDetectSupportedEngines - Windows NT, allowing PrimaryDD winDetectSupportedEngines - Windows NT, allowing PrimaryDD [ 64084.203] winDetectSupportedEngines - DirectDraw4 installed, allowing ShadowDDNL winDetectSupportedEngines - DirectDraw4 installed, allowing ShadowDDNL [ 64084.203] winDetectSupportedEngines - Returning, supported engines 001f winDetectSupportedEngines - Returning, supported engines 001f [ 64084.203] winTaskbarInit - Could not get SHGetPropertyStoreForWindow address winTaskbarInit - Could not get SHGetPropertyStoreForWindow address [ 64084.203] winSetEngine - Multi Window or Rootless = ShadowGDI winSetEngine - Multi Window or Rootless = ShadowGDI [ 64084.203] winScreenInit - Using Windows display depth of 32 bits per pixel winScreenInit - Using Windows display depth of 32 bits per pixel [ 64084.218] winAllocateFBShadowGDI - Creating DIB with width: 1680 height: 1050 depth: 32 winAllocateFBShadowGDI - Creating DIB with width: 1680 height: 1050 depth: 32 [ 64084.218] winFinishScreenInitFB - Masks: 00ff ff00 00ff winFinishScreenInitFB - Masks: 00ff ff00 00ff [ 64084.218] winInitVisualsShadowGDI - Masks 00ff ff00 00ff BPRGB 8 d 24 bpp 32 winInitVisualsShadowGDI - Masks 00ff ff00 00ff BPRGB 8 d 24 bpp 32 [ 64084.218] winInitMultiWindowWM - Calling pthread_mutex_lock () winInitMultiWindowWM - Calling pthread_mutex_lock () [ 64084.218] winMultiWindowXMsgProc - Calling pthread_mutex_lock () winMultiWindowXMsgProc - Calling pthread_mutex_lock () [ 64084.218] MIT-SHM extension disabled due to lack of kernel support MIT-SHM extension disabled due to lack of kernel support [ 64084.218] XFree86-Bigfont extension local-client optimization disabled due to lack of shared memory support in the kernel XFree86-Bigfont extension local-client optimization disabled due to lack of shared memory support in the kernel [ 64084.250] GL_VERSION: 1.5.0 - Build 7.14.10.4964 GL_VERSION: 1.5.0 - Build 7.14.10.4964 [ 64084.250] GL_VENDOR: Intel GL_VENDOR: Intel [ 64084.250] GL_RENDERER:Intel Eaglelake GL_RENDERER:Intel Eaglelake [ 64084.250] GL_EXTENSIONS: GL_ARB_depth_textureGL_EXTENSIONS: GL_ARB_depth_texture GL_ARB_fragment_programGL_ARB_fragment_program GL_ARB_multitextureGL_ARB_multitexture GL_ARB_occlusion_queryGL_ARB_occlusion_query [ 64084.250] GL_EXTENSIONS: GL_EXTENSIONS: GL_ARB_point_parametersGL_ARB_point_parameters GL_ARB_shadowGL_ARB_shadow
Re: startx with different displays
On 2012-04-25 06:50, Marc Girod wrote: Back to my original problem... I tried startxwin (as suggested by a colleague) and this one accepts to start XWin on DISPLAY :0 Are all my problems related to startx? I can see that defaulting to the highest display found in /tmp/.X* seems to comes from it... Does anybody use startx with success? Of course. Yaakov Cygwin/X -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://x.cygwin.com/docs/ FAQ: http://x.cygwin.com/docs/faq/
Re: startx with different displays
Yaakov (Cygwin/X) wrote: Of course. Thanks. Sorry, this was a stupid question: even I use it on my other laptop, without problem. OK: with the two glitches I described. Marc -- View this message in context: http://old.nabble.com/startx-with-different-displays-tp33702991p33749731.html Sent from the cygwin-xfree mailing list archive at Nabble.com. -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://x.cygwin.com/docs/ FAQ: http://x.cygwin.com/docs/faq/
Re: X segmentation fault when particular application attempts to open a window
On 4/25/2012 2:20 PM, Keith Lindsay wrote: Hi, I'm running a data analysis program called ferret on a remote machine that I've logged on to with ssh -X. When the program attempts to create a window, the Cygwin/X server crashes with a segmentation fault. The seg fault is reproducible. xclock works fine from the same remote machine. This is with version 1.12.0-4 of xorg-server. ferret has worked with some previous versions of the Cygwin/X server, but I'm not certain about the precise version where the breakage occurred. I backed up one version and encountered the same problem. I've attached the output of cygcheck -c, the file /var/log/xwin/XWin.0.log, and the output of a gdb that is attached to the XWin process when it crashes. I'm at a loss about how to proceed further. I welcome any advice that you can provide. Thank you, Keith Lindsay Hi again, I realized that I can back up to other versions of xorg-server by installing from the local directory that contains previous version downloads. I have discovered that ferret works fine with version 1.12.0-1 of xorg-server (built 2012-03-12) and generates the segmentation violation with version 1.12.0-2 (built 2012-04-04). Keith -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://x.cygwin.com/docs/ FAQ: http://x.cygwin.com/docs/faq/
