cygwin dlls address issue (cygconv-2.dll), unable to rebaseall

[Ryan Johnson]

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.johnson@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