X-Spam-Check-By: sourceware.org Message-Id: <200611072302.kA7N2aC8029196@www.harkless.org> From: Dan Harkless To: cygwin AT cygwin DOT com Subject: Re: 1.5.21-1: sshd: "child_copy: linked dll data write copy failed" after computer reboot (Windows 2000 SP4) In-Reply-To: Your message of "Tue, 07 Nov 2006 14:48:18 PST." <200611072248.kA7MmIlp028858@www.harkless.org> Date: Tue, 07 Nov 2006 15:02:36 -0800 Received-SPF: pass (www.harkless.org: localhost is always allowed.) X-Greylist: Sender is SPF-compliant, not delayed by milter-greylist-2.0.2 (harkless.org [0.0.0.0]); Tue, 07 Nov 2006 15:02:36 -0800 (PST) X-IsSubscribed: yes Mailing-List: contact cygwin-help AT cygwin DOT com; run by ezmlm Precedence: bulk List-Unsubscribe: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: cygwin-owner AT cygwin DOT com Mail-Followup-To: cygwin AT cygwin DOT com Delivered-To: mailing list cygwin AT cygwin DOT com On November 7, 2006, Dan Harkless wrote: > On November 7, 2006, Brian Dessent wrote: > > Dan Harkless wrote: > > > > > Does this mean setup.exe should be modified to do a rebaseall as the final > > > step of installation, so fresh installs of Cygwin won't be broken > > > out-of-the-box? > > > > This has been discussed in the past. It's not a good idea, because: > > > > - rebaseall is not always needed, only in certain combinations of > > circumstances, so doing it always is a waste of time/effort/extra step > > to go wrong. Most users will never need to do it. > > > > - rebaseall is kind of an ugly hack, a temporary crutch until such time > > as all maitainers have compiled their packages with > > -Wl,--enable-auto-image-base, then we could retire the notion of > > manually assigning base addesses after-the-fact. > > > > - rebaseall currently breaks the emacs package, if installed. > > Only emacs or also xemacs? If the latter, I guess I can't use this, since I > definitely need my Emacs (haven't yet reinstalled it on my fresh Cygwin > install). > > > - rebaseall requires that no files be in use, otherwise it aborts at the > > first DLL it cannot open for writing. Apparently the notion of stopping > > all Cygwin apps/services before running setup.exe is way beyond some > > people, so this would end up being yet another thing that trips them up. > > Well, as it turns out, the rebaseall thing did not permanently fix my > problem anyway. I rebooted a couple of times and was able to ssh in both > times without having to restart sshd. > > However, then my machine was up for a couple of hours, I ran a few programs, > connected and then disconnected my Cisco VPN client (not sure if that has > anything to do with anything -- it never caused problems for my sshd in the > past), and then when I tried to ssh into my Cygwin box, sshd crashed with > the following popup: > > The instruction at "0x61063240" referenced memory at "0x61063240". The > memory could not be "read". > > I had to hit OK several times (due to the client retrying, I guess?). > > On the client side I got the old: > > ssh_exchange_identification: Connection closed by remote host > > Doing a 'ps -ef' showed that the sshd.exe parent process was still running. > > I tried to do 'net stop sshd' and 'net start sshd', but the latter produced: > > The CYGWIN sshd service is starting. > The CYGWIN sshd service could not be started. > > The service did not report an error. > > More help is available by typing NET HELPMSG 3534. > > 'NET HELPMSG 3534' provided no additional insight. > > Running 'net start sshd' again at this point gets the 0x61063240 error popup > again, without even trying to connect with a client. This is repeatable if > I try again. > > Looks like I'll have to reboot to get sshd working again (will do so after > this email). > > Argh, so rebaseall is not a solution for this issue after all. Any thoughts > for what we can try next? Double argh. After rebooting, I found sshd wasn't running at all. Looking at /var/log/sshd.log, I found a ton of: C:\cygwin\usr\sbin\sshd.exe (1584): *** proc magic mismatch detected - 0x704D1F7E/0xD079E02. This problem is probably due to using incompatible versions of the cygwin DLL. Search for cygwin1.dll using the Windows Start->Find/Search facility and delete all but the most recent version. The most recent version *should* reside in x:\cygwin\bin, where 'x' is the drive on which you have installed the cygwin distribution. Rebooting is also suggested if you are unable to find another cygwin DLL. errors, and interspersed between them there were three: 16 [main] sshd 1208 fork: child -1 - died waiting for longjmp before initialization, retry 0, exit code 0x80, errno 11 errors. The second two copies had "91234694" and "96508326" instead of "16" but were otherwise identical. (It would certainly be helpful if these errors had timestamps, BTW.) Trying 'net start sshd' at this point gets the 0x61063240 error popup again. Guess I have to reinstall Cygwin again to get sshd back to its semi-working (just not after a reboot) state? -- Dan Harkless http://harkless.org/dan/ -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/