Re: mintty system integration before release
On 01.07.2015 12:47, Corinna Vinschen wrote: On Jun 27 17:59, Thomas Wolff wrote: ... I think it's sufficient for this project to have one of issue tracker or mailing list/forum, not both. And an issue tracker has the valuable advantage that you can close issues... Mailing lists allow discussing stuff before formally requesting something via issue tracker. E.g, user problems can be both, a user just having a thinko or a bug. ML discussions help to find out and avoid spurious issues in the issue tracker. Also, many people happily report bugs on mailing lists but don't want to be bothered with issue trackers which you have to login to. Sure. My assumption was that cygwin@cygwin.com would be a good place for occasional questions of that kind. Also I had somewhat associated the google groups list with the closing google code area but that's probably not proper. If you prefer to divert traffic off this list, I'll reconsider. Also, if people start discussions on the old list, I can still mention it on the homepage. I have a package now to publish but need to find a timeslot to fiddle with the lftp upload... Thomas (wondering why my responses get lost if sent from one of my machines...) -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Re: mintty system integration before release
On Jul 3 10:08, Thomas Wolff wrote: > On 01.07.2015 12:47, Corinna Vinschen wrote: > >On Jun 27 17:59, Thomas Wolff wrote: > >>... > >>I think it's sufficient for this project to have one of issue tracker or > >>mailing list/forum, not both. And an issue tracker has the valuable > >>advantage that you can close issues... > >Mailing lists allow discussing stuff before formally requesting > >something via issue tracker. E.g, user problems can be both, a user > >just having a thinko or a bug. ML discussions help to find out and > >avoid spurious issues in the issue tracker. Also, many people happily > >report bugs on mailing lists but don't want to be bothered with > >issue trackers which you have to login to. > Sure. My assumption was that cygwin@cygwin.com would be a good place for > occasional questions of that kind. That's fine, but that only covers the cygwin users, while mintty exists in a non-Cygwin version as well, IIRC. I was just outlining why I think having a mailing list is a good thing. Ultimately it's your (and perhaps Andy's) call. > Also I had somewhat associated the google groups list with the closing > google code area but that's probably not proper. > If you prefer to divert traffic off this list, I'll reconsider. Also, if > people start discussions on the old list, I can still mention it on the > homepage. > > I have a package now to publish but need to find a timeslot to fiddle with > the lftp upload... /me is jumping up and down in anticipation Thanks, Corinna -- Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Maintainer cygwin AT cygwin DOT com Red Hat pgpHOfrXaZ4NC.pgp Description: PGP signature
Re: latest tcsh build has problems completing ln -s
On Jul 2 19:56, Lester Ingber wrote: > Since the newest tcsh build on Cygwin (i'm using cygwin64), > version tcsh 6.19.00 (Astron) 2015-05-21 (x86_64-unknown-cygwin) options > wide,nls,dl,al,kan,sm,rh,color > the completion of files using TAB does not work anymore. > It works fine under bash. > > I've inserted [TAB] where I have pressed Tab. > On tcsh I just get " as a response. > The problem only occurs with trying soft links "ln -s" not hard links "ln". > > 12:34:48pm ingber@lesterX1:~% touch tp1 > 12:35:00pm ingber@lesterX1:~% ln -s ./t [TAB] > > 12:35:00pm ingber@lesterX1:~% ln -s ./tp1 tp2 > 12:35:15pm ingber@lesterX1:~% ls -l > -rw-r--r-- 1 ingber Users 0 Jul 2 12:35 tp1 > lrwxrwxrwx 1 ingber Users 5 Jul 2 12:35 tp2 -> ./tp1 > 12:38:09pm ingber@lesterX1:~% bash > [12:38:13 ingber@lesterX1 ~]$ touch tp3 > [12:38:23 ingber@lesterX1 ~]$ ln -s ./tp [TAB] > tp1 tp2 tp3 > [12:38:23 ingber@lesterX1 ~]$ ln -s ./tp3 tp4 > [12:39:22 ingber@lesterX1 ~]$ ls -l > -rw-r--r-- 1 ingber Users 0 Jul 2 12:35 tp1 > lrwxrwxrwx 1 ingber Users 5 Jul 2 12:35 tp2 -> ./tp1 > -rw-r--r-- 1 ingber Users 0 Jul 2 12:38 tp3 > lrwxrwxrwx 1 ingber Users 5 Jul 2 12:38 tp4 -> ./tp3 > > I've compiled the new tcsh on several linux platforms, > and this problem does not occur. Yes, it does. I just tested it on Linux and the same problem occurs. It depends on whether you use the default completions from /etc/profile.d/complete.tcsh or not. Usually I don't (setting `uncomplete *' in my .cshrc), neither on Cygwin nor on Linux. So, yes, if I use the `ln' completion from /etc/profile.d/complete.tcsh, I can reproduce this problem on Linux and Cygwin with tcsh-6.19, while it works as expected on tcsh-6.18. Looks like an upstream bug to me. I'll report it to the maintainer. Thanks, Corinna -- Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Maintainer cygwin AT cygwin DOT com Red Hat pgpm7VfzU0INJ.pgp Description: PGP signature
Re: [ANNOUNCEMENT] TEST RELEASE: Cygwin 2.1.0-0.1
On Jul 2 15:25, Ken Brown wrote:
> On 7/2/2015 8:20 AM, Corinna Vinschen wrote:
> >On Jul 2 14:13, Corinna Vinschen wrote:
> >>On Jul 1 22:10, Ken Brown wrote:
> >>>I may have spoken too soon. As I repeat the experiment on a different
> >>>computer, with a build from a slightly different snapshot of the emacs
> >>>trunk, emacs crashes when I type 'C-x d' with the following stack dump:
> >>>
> >>>Stack trace:
> >>>FrameFunctionArgs
> >>>00100A3E240 00180071CC3 (0829630, 08296D0, 000,
> >>>082CE00)
> >>>0003002 001800732BE (000, 002, 00100A48C80,
> >>>002)
> >>>000 0006B40 (002, 00100A48C80, 002,
> >>>00100A48768)
> >>>000 213 (002, 00100A48C80, 002,
> >>>00100A48768)
> >>>End of stack trace
> >>>
> >>>$ addr2line 00180071CC3 -e /usr/lib/debug/usr/bin/cygwin1.dbg
> >>>/usr/src/debug/cygwin-2.1.0-0.3/winsup/cygwin/exception.h:175
> >>>
> >>>$ addr2line 001800732BE -e /usr/lib/debug/usr/bin/cygwin1.dbg
> >>>/usr/src/debug/cygwin-2.1.0-0.3/winsup/cygwin/exceptions.cc:1639
> >>
> >>That points to a crash while setting up the alternate stack. This is
> >>always a possibility because, in contrast to the kernel signal handler
> >>in a real POSIX system, the Cygwin exception handler is still running on
> >>the stack which triggered the crash up to the point where we call the
> >>signal handler function. Dependent on how the stack overflow occured,
> >>this additional stack usage may be enough to kill the process for good.
> >>
> >>Out of curiosity, can you add this to the init_sigsegv() function:
> >>
> >> #include
> >> [...]
> >> init_sigsegv (void)
> >> {
> >> [...]
> >> SetThreadStackGuarantee (65536);
> >
> >Of course this only works "per thread", so if init_sigsegv is called
> >for the main thread, only the main thread gets this treatment. For
> >testing this should be enough, though.
>
> That didn't make any difference.
It should have. If you don't also tweak STACK_DANGER_ZONE accordingly,
handle_sigsegv should fail to call siglongjmp. Either way, I tested
it locally as well, and it doesn't work.
In the meantime I found that there's another problem. Assuming you
longjmp out of handle_sigsegv, the stack will still be "broken".
It doesn't have the usual guard pages anymore, and the next time
you have a stack overflow, NTDLL will simply terminate the process.
I create a wrapper function which resets the stack so it has valid guard
pages again and then the stack overflow can be handled repeatedly.
While I was at it, I found that the setup for pthread stacks is not
quite right, either, so right now I'm hacking on this stuff to make
it behave as expected in the usual cases.
> But I do have a little more information.
> I tried running emacs under gdb with a breakpoint at handle_sigsegv. The
> breakpoint is hit when I deliberately trigger the stack overflow. Then I
> continue, emacs says it has recovered from the stack overflow, and I type
> 'C-x d'. At this point there's a second SIGSEGV and handle_sigsegv is
> called again. But this time garbage collection is in progress, and
> handle_sigsegv just gives up.
Sounds right to me.
> I don't know what caused the second SIGSEGV but I'll try to figure that out
> when I next have a chance to look at this. I also don't know why the stack
> dump pointed to a crash while setting up the alternate stack, since the
> fatal crash actually seems to have happened later. But maybe the stack was
> just completely messed up after the second SIGSEGV and the stack dump can't
> be trusted.
>
> More later.
Thanks!
Corinna
--
Corinna Vinschen Please, send mails regarding Cygwin to
Cygwin Maintainer cygwin AT cygwin DOT com
Red Hat
pgppZowNuzHTt.pgp
Description: PGP signature
[ANNOUNCEMENT] Updated: gcc-4.9.3-1 (x86/x86_64)
gcc-4.9.3-1 has been uploaded for 32bit and 64bit Cygwin. This is a refresh build for 4.9.2 without any new additions. *** CYGWIN-ANNOUNCE UNSUBSCRIBE INFO *** If you want to unsubscribe from the cygwin-announce mailing list, look at the "List-Unsubscribe: " tag in the email header of this message. Send email to the address specified there. It will be in the format: cygwin-announce-unsubscribe-you=yourdomain.com cygwin.com If you need more information on unsubscribing, start reading here: http://sourceware.org/lists.html#unsubscribe-simple Please read *all* of the information on unsubscribing that is available starting at this URL. signature.asc Description: OpenPGP digital signature
Re: [ANNOUNCEMENT] TEST RELEASE: Cygwin 2.1.0-0.1
On Jul 3 12:47, Corinna Vinschen wrote: > In the meantime I found that there's another problem. Assuming you > longjmp out of handle_sigsegv, the stack will still be "broken". > It doesn't have the usual guard pages anymore, and the next time > you have a stack overflow, NTDLL will simply terminate the process. > > I create a wrapper function which resets the stack so it has valid guard > pages again and then the stack overflow can be handled repeatedly. s/create/created/ I didn't push it yet, though. Still hacking. Corinna -- Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Maintainer cygwin AT cygwin DOT com Red Hat pgpu6_xKtXEyS.pgp Description: PGP signature
Re: [ANNOUNCEMENT] TEST RELEASE: Cygwin 2.1.0-0.1
On 7/3/2015 6:47 AM, Corinna Vinschen wrote:
On Jul 2 15:25, Ken Brown wrote:
On 7/2/2015 8:20 AM, Corinna Vinschen wrote:
On Jul 2 14:13, Corinna Vinschen wrote:
On Jul 1 22:10, Ken Brown wrote:
I may have spoken too soon. As I repeat the experiment on a different
computer, with a build from a slightly different snapshot of the emacs
trunk, emacs crashes when I type 'C-x d' with the following stack dump:
Stack trace:
FrameFunctionArgs
00100A3E240 00180071CC3 (0829630, 08296D0, 000, 082CE00)
0003002 001800732BE (000, 002, 00100A48C80, 002)
000 0006B40 (002, 00100A48C80, 002, 00100A48768)
000 213 (002, 00100A48C80, 002, 00100A48768)
End of stack trace
$ addr2line 00180071CC3 -e /usr/lib/debug/usr/bin/cygwin1.dbg
/usr/src/debug/cygwin-2.1.0-0.3/winsup/cygwin/exception.h:175
$ addr2line 001800732BE -e /usr/lib/debug/usr/bin/cygwin1.dbg
/usr/src/debug/cygwin-2.1.0-0.3/winsup/cygwin/exceptions.cc:1639
That points to a crash while setting up the alternate stack. This is
always a possibility because, in contrast to the kernel signal handler
in a real POSIX system, the Cygwin exception handler is still running on
the stack which triggered the crash up to the point where we call the
signal handler function. Dependent on how the stack overflow occured,
this additional stack usage may be enough to kill the process for good.
Out of curiosity, can you add this to the init_sigsegv() function:
#include
[...]
init_sigsegv (void)
{
[...]
SetThreadStackGuarantee (65536);
Of course this only works "per thread", so if init_sigsegv is called
for the main thread, only the main thread gets this treatment. For
testing this should be enough, though.
That didn't make any difference.
It should have. If you don't also tweak STACK_DANGER_ZONE accordingly,
handle_sigsegv should fail to call siglongjmp. Either way, I tested
it locally as well, and it doesn't work.
In the meantime I found that there's another problem. Assuming you
longjmp out of handle_sigsegv, the stack will still be "broken".
It doesn't have the usual guard pages anymore, and the next time
you have a stack overflow, NTDLL will simply terminate the process.
I create a wrapper function which resets the stack so it has valid guard
pages again and then the stack overflow can be handled repeatedly.
While I was at it, I found that the setup for pthread stacks is not
quite right, either, so right now I'm hacking on this stuff to make
it behave as expected in the usual cases.
But I do have a little more information.
I tried running emacs under gdb with a breakpoint at handle_sigsegv. The
breakpoint is hit when I deliberately trigger the stack overflow. Then I
continue, emacs says it has recovered from the stack overflow, and I type
'C-x d'. At this point there's a second SIGSEGV and handle_sigsegv is
called again. But this time garbage collection is in progress, and
handle_sigsegv just gives up.
Sounds right to me.
I don't know what caused the second SIGSEGV but I'll try to figure that out
when I next have a chance to look at this. I also don't know why the stack
dump pointed to a crash while setting up the alternate stack, since the
fatal crash actually seems to have happened later. But maybe the stack was
just completely messed up after the second SIGSEGV and the stack dump can't
be trusted.
I think I found the cause of that second SIGSEGV, and, if I'm right, it has
nothing to do with Cygwin. I think the problem was that in my testing, I forgot
to reset max-specpdl-size and max-lisp-eval-depth to reasonable values after the
recovery from stack overflow. If I do that, then I can no longer reproduce the
crash.
For the record, here's my complete elisp test case:
(setq max-specpdl-size 8320
max-lisp-eval-depth 64)
(defun foo () (foo))
(foo)
;; The stack has now overflowed, and emacs has recovered.
(setq max-specpdl-size 1300
max-lisp-eval-depth 800)
;; Can now continue working.
Ken
--
Problem reports: http://cygwin.com/problems.html
FAQ: http://cygwin.com/faq/
Documentation: http://cygwin.com/docs.html
Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
[ANNOUNCEMENT] Updated: Git v2.4.5
Version 2.4.5-1 of Git has been uploaded and should be coming soon to a mirror near you. This update includes the following packages: - git - git-completion - git-cvs - git-debuginfo - git-email - git-gui - gitk - git-svn This is an update to the latest upstream release. For a full list of the upstream changes in this release, please refer to the upstream changelogs: https://git.kernel.org/cgit/git/git.git/tree/Documentation/RelNotes -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
[ANNOUNCEMENT] Updated: dos2unix 7.2.3-1
CHANGES SINCE LAST RELEASE: === New upstream release. * Fix: Check for file I/O errors while reading input files, and added a few missing checks while writing output files. * Fix: Compilation for msys. homepage: http://waterlan.home.xs4all.nl/dos2unix.html license: 2-clause BSD (FreeBSD) -- Erwin Waterlander http://waterlan.home.xs4all.nl/ -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Release: mintty 2.0.1
After closing half of the open issues, I thought it’s a good time to
release mintty.
I’ve bumped the major version number to 2 to reflect the change of
repository and maintainer and somehow catch up with cygwin...
Major new features and fixes are listed below. See also the changelog in
the Wiki
https://github.com/mintty/mintty/wiki
For new options, there is no GUI configuration facility yet ("Hidden
settings"). Please ask for them if desired.
The homepage is at http://mintty.github.io/
It also links to the issue tracker.
Major new features and fixes
Display:
* Fixed bold display by overstriking if BoldAsFont unset.
* Implemented and enabled character attribute italic (#418, #152).
* Implemented character attribute strikeout; disabled due to missing bit.
* True Colour support (#431) (using ESC [ 38;2;r;g;b m).
Window:
* Alt-F2 creates new window of same size as current one (#275).
* Option -T to set unchangeable window title (#385).
Keyboard:
* Option DeleteSendsDEL and associated switching sequence CSI ? 1037
h/l to switch keypad Del key sending DEL or Remove (#406).
* Options Break and Pause to configure mappings for these keys (#399).
Other Options:
* Configuration option WordCharsExcl to exclude characters from word
selection (#450).
* Added configuration options BellType, BellFreq, BellLen (~ #369).
* Option HideMouse=false disables mouse cursor hiding on keyboard
input (#403).
* Option MiddleClickAction=void disables mouse-middle-click pasting
(#384).
* Option to simulate Enter/Return with mouse-click (#425).
* Documented RowSpacing/ColSpacing; tweaked to distribute padding evenly.
--
Thomas
--
Problem reports: http://cygwin.com/problems.html
FAQ: http://cygwin.com/faq/
Documentation: http://cygwin.com/docs.html
Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Re: Release: mintty 2.0.1
On 2015-07-03 23:18, Thomas Wolff wrote: > * Option MiddleClickAction=void disables mouse-middle-click pasting (#384) Yay, and thanks. I wonder if that uses my patch. I can't wait for my mirror to get the package so I can see. signature.asc Description: OpenPGP digital signature
[ANNOUNCEMENT] Release: mintty 2.0.1
After closing half of the open issues, I thought it’s a good time to
release mintty.
I’ve bumped the major version number to 2 to reflect the change of
repository and maintainer and somehow catch up with cygwin...
Major new features and fixes are listed below. See also the changelog in
the Wiki
https://github.com/mintty/mintty/wiki
For new options, there is no GUI configuration facility yet ("Hidden
settings"). Please ask for them if desired.
The homepage is at http://mintty.github.io/
It also links to the issue tracker.
Major new features and fixes
Display:
* Fixed bold display by overstriking if BoldAsFont unset.
* Implemented and enabled character attribute italic (#418, #152).
* Implemented character attribute strikeout; disabled due to missing bit.
* True Colour support (#431) (using ESC [ 38;2;r;g;b m).
Window:
* Alt-F2 creates new window of same size as current one (#275).
* Option -T to set unchangeable window title (#385).
Keyboard:
* Option DeleteSendsDEL and associated switching sequence CSI ? 1037
h/l to switch keypad Del key sending DEL or Remove (#406).
* Options Break and Pause to configure mappings for these keys (#399).
Other Options:
* Configuration option WordCharsExcl to exclude characters from word
selection (#450).
* Added configuration options BellType, BellFreq, BellLen (~ #369).
* Option HideMouse=false disables mouse cursor hiding on keyboard
input (#403).
* Option MiddleClickAction=void disables mouse-middle-click pasting
(#384).
* Option to simulate Enter/Return with mouse-click (#425).
* Documented RowSpacing/ColSpacing; tweaked to distribute padding evenly.
--
Thomas
--
Problem reports: http://cygwin.com/problems.html
FAQ: http://cygwin.com/faq/
Documentation: http://cygwin.com/docs.html
Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Cygwin X11 server won't start
I had a Windows 7 crash this afternoon and now Cygwin/X server won't start. I've attached a couple files. Any idea how to correct this? Things have been OK for weeks. I'm worried about these two items: [33.977] Could not load crashreporter dll [48.438] (EE) Error compiling keymap (server-0) My ~/.startxwinrc contains: xrdb ~/.Xresources sleep infinity I tried removing the file, but the problem continues. Thanks - Jim [33.977] Could not load crashreporter dll [34.008] (II) xorg.conf is not supported [34.008] (II) See http://x.cygwin.com/docs/faq/cygwin-x-faq.html for more information [34.023] LoadPreferences: Loading /cygdrive/D/Home/.XWinrc [34.023] LoadPreferences: Done parsing the configuration file... [34.039] winDetectSupportedEngines - DirectDraw4 installed, allowing ShadowDDNL [34.039] winDetectSupportedEngines - Returning, supported engines 0005 [34.039] winSetEngine - Multi Window or Rootless => ShadowGDI [34.039] winScreenInit - Using Windows display depth of 32 bits per pixel [34.055] winAllocateFBShadowGDI - Creating DIB with width: 3840 height: 1200 depth: 32 [34.055] winFinishScreenInitFB - Masks: 00ff ff00 00ff [34.055] winInitVisualsShadowGDI - Masks 00ff ff00 00ff BPRGB 8 d 24 bpp 32 [34.070] MIT-SHM extension disabled due to lack of kernel support [34.086] XFree86-Bigfont extension local-client optimization disabled due to lack of shared memory support in the kernel [34.086] glWinSelectGLimplementation: Loaded 'cygnativeGLthunk.dll' [34.179] (II) AIGLX: Testing pixelFormatIndex 5 [34.195] GL_VERSION: 4.5.0 NVIDIA 353.06 [34.195] GL_VENDOR: NVIDIA Corporation [34.195] GL_RENDERER:GeForce GT 720/PCIe/SSE2 [34.195] (II) AIGLX: enabled GLX_SGI_make_current_read [34.195] (II) AIGLX: enabled GLX_MESA_copy_sub_buffer [34.195] (II) AIGLX: enabled GLX_SGI_swap_control and GLX_MESA_swap_control [34.195] (II) AIGLX: enabled GLX_SGIX_pbuffer [34.195] (II) AIGLX: enabled GLX_ARB_multisample and GLX_SGIS_multisample [34.195] (II) 482 pixel formats reported by wglGetPixelFormatAttribivARB [34.211] (II) AIGLX: Set GLX version to 1.4 [34.211] (II) 323 fbConfigs [34.211] (II) ignored pixel formats: 0 not OpenGL, 54 RBGA float, 69 RGBA unsigned float, 0 unknown pixel type, 36 unaccelerated [34.211] (II) GLX: Initialized Win32 native WGL GL provider for screen 0 [48.438] (EE) Error compiling keymap (server-0) [48.438] (EE) xkbcomp exit status 32512 [48.453] (EE) XKB: Couldn't compile keymap [48.453] (EE) XKB: Failed to load keymap. Loading default keymap instead. [48.531] (EE) Error compiling keymap (server-0) [48.531] (EE) xkbcomp exit status 32512 [48.531] (EE) XKB: Couldn't compile keymap [48.531] XKB: Failed to compile keymap [48.531] Keyboard initialization failed. This could be a missing or incorrect setup of xkeyboard-config. [48.531] (EE) Fatal server error: [48.531] (EE) Failed to activate core devices.(EE) [48.531] (EE) Server terminated with error (1). Closing log file. -- Jim Reisert AD1C, , http://www.ad1c.us cygcheck.out Description: Binary data XWin.0.log Description: Binary data -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Re: Cygwin X11 server won't start
On 7/4/2015 6:12 AM, Jim Reisert AD1C wrote: I had a Windows 7 crash this afternoon and now Cygwin/X server won't start. I've attached a couple files. Any idea how to correct this? Things have been OK for weeks. Thanks - Jim [48.438] (EE) Error compiling keymap (server-0) [48.438] (EE) xkbcomp exit status 32512 it looks like recent: https://cygwin.com/ml/cygwin/2015-06/msg00149.html [48.453] (EE) XKB: Couldn't compile keymap [48.453] (EE) XKB: Failed to load keymap. Loading default keymap instead. [48.531] (EE) Error compiling keymap (server-0) [48.531] (EE) xkbcomp exit status 32512 [48.531] (EE) XKB: Couldn't compile keymap [48.531] XKB: Failed to compile keymap [48.531] Keyboard initialization failed. This could be a missing or incorrect setup of xkeyboard-config. [48.531] (EE) Fatal server error: [48.531] (EE) Failed to activate core devices.(EE) [48.531] (EE) Server terminated with error (1). Closing log file. -- Jim Reisert AD1C, , http://www.ad1c.us Likely unrelated, but noticed from your cygcheck.out I hope for you that you are resetting the path order inside bash. D:\ActiveState Perl Dev Kit 9.4\bin D:\Perl\site\bin D:\Perl\bin C:\Windows\system32 C:\Windows D:\WATCOM\BINNT D:\WATCOM\BINW C:\Cygwin\bin ... Found: C:\Cygwin\bin\find.exe Warning: C:\Windows\system32\find.exe hides C:\Cygwin\bin\find.exe ... Found: D:\Perl\bin\perl.exe Found: C:\Cygwin\bin\perl.exe Warning: D:\Perl\bin\perl.exe hides C:\Cygwin\bin\perl.exe Regards Marco -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Re: Cygwin X11 server won't start
I am happy to report that I found the culprit. While installing another piece of software today, "Lavasoft Web Companion" came along as a stow-away. Unfortunately, there is no easy way to remove this @#$%^& program, and I ended up corrupting my registry in the process. I was able to restore my C:\ (boot) partition from last night's backup and all is well now. NOTE TO SELF: when an installation program offers you advanced options, LOOK AT THEM! In my case, there was an option to NOT install the extra unwanted software. - Jim -- Jim Reisert AD1C, , http://www.ad1c.us -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
