I have the very same problem, not at startup, but when compiling a few packages. Killing all the windows aplications and processes would help with some packages, but not all. Which makes cygwin completely useless.
Massi 2012/11/26 Ryan Johnson <ryan.john...@cs.utoronto.ca>: > On 26/11/2012 2:47 PM, Piren wrote: >> >> Thanks for the response Ryan >> >> I'm seeing the same issues no matter what runs on Windows, it does the >> same even in Safe Mode. Also, this issue only started once i updated >> to the new Cygwin version and my windows configuration/installed apps >> did not change. >> >> ATM Cygwin is completely non functional, is there nothing i can do to >> try and resolve this? > > If you're really desperate, rename your cygwin directory to something else > (e.g. cygwin.broken) and see if reinstalling from scratch fixes it. All the > packages should still be cached (no new downloads) and that will rule out > any misconfiguration. If the fresh version is broken I have no idea what to > do after that; if it works, just migrate your $HOME over and problem solved. > > Ryan > > >> >> On Mon, Nov 26, 2012 at 12:09 PM, Ryan Johnson >> <ryan.john...@cs.utoronto.ca> wrote: >>> >>> Hi Uri, >>> >>> >>> On 26/11/2012 11:33 AM, Piren wrote: >>>> >>>> Hi >>>> >>>> I've been using Cygwin for a while and everything was working fine. >>>> i've updated Cygwin to the latest version s 1.7.17-1. and even since >>>> i'm unable to use it anymore. >>>> I'm getting this message shown on every start of cygwin and it never >>>> becomes operational: >>>> 0 [main] bash 6156 child_info_fork::abort: >>>> C:\cygwin\bin\cygiconv-2.dll: Loaded to different address: >>>> parent(0x490000) != child(0x630000) >>>> bash: fork: retry: Resource temporarily unavailable >>> >>> We usually associate fork() failures with a messed-up child process, but >>> that error message usually indicates that the parent is the one with >>> problems [1]. If you're starting from a command shell or other persistent >>> process, you might try restarting it in hopes that Windows gives the next >>> one a better address space layout. Otherwise, I don't know what to tell >>> you >>> (WFM w/ same version of Windows), other than to make sure things like >>> SlickSVN aren't bundling some other version of cygwin that's messing >>> everything up (unlikely, since cygcheck didn't complain). >>> >>> [1] What likely happened is that Windows put "something" at 0x630000 and >>> forced cygiconv-2 to rebase; if that "something" moves out of the way in >>> the >>> forked child, cygiconv-2 will then attempt to go where it "should" go, >>> giving a mismatch. For dynamically loaded dlls, cygwin can work around >>> this >>> by unloading the library, and then filling the offending address space >>> with >>> padding that forces it to go where desired, but cygiconv is usually >>> statically linked and therefore untouchable (attempts to unload it are >>> silently ignored by Windows). >>> >>> >>>> i've tried rebaseasll, with a variety of open memory allocations but >>>> nothing works. >>> >>> I've had poor luck with anything but the default base address, because >>> the >>> address space is crowded both above and below it. Fine line rebase has to >>> walk... >>> >>> Ryan >>> >>> >>> -- >>> 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 >>> >> -- >> 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 >> > > > -- > 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 > -- 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
