This is the mail archive of the cygwin mailing list for the Cygwin project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: 1.7 fork errors in Win7


Eliot,

I got some time to re-read the rebase read me file this weekend and
I'm now a bit more uncertain about your recommendation.  If I
understand correctly, you're saying I should mark ALL (almost at
least, I don'tknow  what not to yet) dlls, exes and sos as not ASLR
compatible and then rebase with enough space between them so they are
separate enough that they can be loaded in the same place by Window's
loader without conflict.

So, it seems we are simply taking the Windows loader out of the
business of loading DLLs et all in the same memory location for all
concurrent processes.

If so, then:

How do I figure out what binaries don't need to be rebased and
peflaged?  Trial and error?
Why not use rebaseall and peflagsall instead?

Thanks,

Luis P Caamano
Atlanta, GA USA



On Wed, Dec 2, 2009 at 3:41 PM, Luis P Caamano wrote:
> On Wed, Dec 2, 2009 at 3:29 PM, ?Eliot Moss, wrote
>>
>> Date:?Wed, 02 Dec 2009 11:43:44 -0500
>> Subject:?Re: 1.7 fork errors in Win7
>> Luis P Caamano wrote:
>>>
>>> I'm running 1.7.0-67 on Windows 7 64 bit:
>>>
>>> $ uname -v
>>> 2009-11-27 15:38
>>>
>>> and I'm getting sporadic for errors like this one:
>>>
>>> $ svn commit -m "xxx yyy"
>>> ? ? ?2 [main] svn 5924 fork: child -1 - died waiting for longjmp
>>> before initialization, retry 0, exit code 0xC0000005, errno 11
>>> svn: Commit failed (details follow):
>>> svn: Can't create tunnel: Resource temporarily unavailable
>>>
>>> This is not limited to svn of course, just one example. ?My cygwin
>>> environment is very usable as these are not that frequent but every
>>> time I'm thinking all is well, one of these comes up to remind me it's
>>> not.
>>>
>>> Is this a known issue?
>>> Is there any information I can provide to help debug and fix this?
>>> Is there anything I can do on my end to investigate the issue?
>>>
>>> Thanks in advance for all your work on 1.7, it's looking good.
>>
>> This "smells" like collisions with Windows dll's, which can happen
>> somewhat randomly because of Address Space Randomization in recent
>> Windows OSs. ?What fixes it for me is suitably rebasing all cygwin
>> dll, so, and exe files appropriately.
>>
>> Details:
>>
>> /bin/rebase -d -b 0x61000000 -o 0x20000 -v -T <file with list of dll and so files> > rebase.out
>>
>> and
>>
>> /bin/peflags -d0 -v -T <file with list of dll and so files> > peflags-d.out
>> /bin/peflags -t0 -v -T <file with list of exe files> ? ? ? ?> peflags-t.out
>>
>> Corinna and others say that this should not be necessary, but I get problems
>> with certain forking programs if I don't do it. Note the -o flag, which makes
>> sure that items are far enough apart that certain metadata does not cause
>> problems.
>>
>> Do read up on how to use rebase and peflags! They need to be called from ash,
>> not bash, since otherwise soe of the dll's will be open. Also, I have found
>> the need to drop one or two specific files from the list of *all* so, dll, and
>> exe files that I build with find, so do check the output, etc.
>>
>> Regards -- Eliot Moss
>>

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


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]