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: Updated: perl-5.8.7-2


On Mon, Jul 11, 2005 at 10:17:51PM -0400, Christopher Faylor wrote:
>On Mon, Jul 11, 2005 at 11:29:10PM +0200, Gerrit P. Haase wrote:
>>Adye, TJ (Tim) wrote:
>>>Thanks for the Perl update.
>>>
>>>Unfortunately this doesn't seem to fix the problem I reported earlier
>>>("Perl Win32::Shortcut screws up fork").  My test script worked fine
>>>after "rebaseall", but when I reinstalled Cygwin from scratch (including
>>>Perl 5.8.7-2) it dies with
>>>
>>>C:\cygwin\bin\perl.exe (3772): *** unable to remap
>>>C:\cygwin\lib\perl5\vendor_perl\5.8\cygwin\auto\Win32\Shortcut\Shortcut.
>>>dll to same address as parent(0x950000) != 0xBF0000
>>>     17 [main] perl 3448 fork_parent: child 3772 died waiting for dll
>>>loading
>>>
>>>The addresses are now different, if that's any consolation (previously
>>>it reported parent(0xBF0000) != 0x1110000).
>>>
>>>Presumably "rebaseall" will fix it again, but I'll keep the pristine
>>>Cygwin installation for further tests if that's helpful.
>>
>>Jason said it in the "Perl Win32::Shortcut screws up fork" thread,
>>auto-image-base helps but it doesn't resolve all issues.  A certain
>>amount of pad is required between the base DLL addresses and it seems
>>that this is one of those cases where the padding is too small.
>
>I really can't see why this padding would be needed for fork.  If the dlls are
>in the same place in the parent and the child (as should be the case after
>an auto-image-base) then fork() shouldn't care where they're located.  It is
>only when some dlls are not correctly based and some are that I could see
>problems.
>
>In any event, if the problem really does occur, even with all dlls
>correctly based, there's certainly no reason to stand on our heads trying
>to accommodate cygwin behavior.  We golly gee just might be able to fix
>cygwin if we have a reproducible test case.

Nevermind.  I should have taken my own implied advice and looked at the
source.  Cygwin does put location information in an alloced block after
the dll so it does need some memory after each dll.  However, it is just
a simple matter of programming to fix this.

cgf

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


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