Message-Id: <200611072322.kA7NMs9C029741@www.harkless.org>
From: Dan Harkless <cygwin-list AT harkless DOT org>
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 15:02:36 PST."              <200611072302.kA7N2aC8029196@www.harkless.org>
Date: Tue, 07 Nov 2006 15:22:54 -0800
Received-SPF: pass (www.harkless.org: localhost is always allowed.)
Mailing-List: contact cygwin-help AT cygwin DOT com; run by ezmlm
Precedence: bulk
Sender: cygwin-owner AT cygwin DOT com
Mail-Followup-To: cygwin AT cygwin DOT com


On November 7, 2006, Dan Harkless <cygwin-list AT harkless DOT org> wrote:
> On November 7, 2006, Dan Harkless <cygwin-list AT harkless DOT org> wrote:
> > On November 7, 2006, Brian Dessent <brian AT dessent DOT net> 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?

Sorry for the multiple emails, and I don't want to trim away the text above
before people get the chance to responsd to it, but I wanted to add that I
tried doing another 'rebaseall' and it didn't get sshd working again.  

I thus reinstalled Cygwin from scratch again, and this time when running
ssh-host-config told it not to use privilege separation, to see if that
would make any difference, but after rebooting, sshd is doing the:

       13 [main] sshd 1208 child_copy: linked dll data write copy failed, 
  0x33F000..0x33F050, done 0, windows pid 2276708, Win32 error 487

bit again.  'net stop sshd' and 'net start sshd' and I can get in.

-- 
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/