This is the mail archive of the
mailing list for the Cygwin project.
Re: Doing vfork: resource temporarily unavailable
- From: Achim Gratz <Stromeko at nexgo dot de>
- To: cygwin at cygwin dot com
- Date: Tue, 26 May 2015 18:39:47 +0200
- Subject: Re: Doing vfork: resource temporarily unavailable
- Authentication-results: sourceware.org; auth=none
- References: <86pp5vlfwq dot fsf at example dot com> <555C8066 dot 8080009 at cornell dot edu> <CAK-n8j41UL6x867NUb3ZBrEkWiyQcC7+a1J7Qwa_yuTv=+MyUA at mail dot gmail dot com> <3d9c900f406e4f4289c23e8f14b9304b at vsrv060ex01 dot ssd dot fsi dot com> <vriu4mmzvj65 dot fsf at example dot com> <edbc68784f8747d0bb532f3a2b44f181 at vsrv060ex01 dot ssd dot fsi dot com>
Rockefeller, Harry writes:
> Instructions above state running setup-x86.exe not setup-x86_64.exe.
> Does anyone experience frequent emacs vfork errors running 64-bit Cygwin?
> Maybe it's time for me to try running that again?
DLL collisions are _much_ less likely on x86_64 out of the gate, but
they do occur from time to time.
> What I've successfully done, twice :-), to fix my vfork errors is to follow the
> above procedure: run rebase-trigger, stop all Cygwin, then run setup-x86.exe,
> followed by a reboot, then bring up cmd window where I run,
> cd c:/cygwin; cd bin; ash; /usr/bin/rebaseall -v
That's the wrong procedure. You run
then reboot (if you have reason to suspect that a reboot might help,
then run setup.exe (either architecture). An additional rebaseall
beyond that isn't going to do anything useful. A full rebase on the
same installation is deterministic, it will always chose the same base
+<[Q+ Matrix-12 WAVE#46+305 Neuron microQkb Andromeda XTk Blofeld]>+
SD adaptations for Waldorf Q V3.00R3 and Q+ V3.54R2:
Problem reports: http://cygwin.com/problems.html
Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple