Perl Win32::Shortcut screws up fork

Perl Win32::Shortcut screws up fork

[Adye, TJ (Tim)]

Hi,

In an attempt to work round the problem with readshortcut I reported
earlier, I thought I'd use a Perl script. Unfortunately the
Win32::Shortcut package seems to cause problems with process forking
(unlike the readshortcut error, this one isn't specific to the latest
cygwin DLL). I get an error

C:\cygwin\bin\perl.exe (3088): *** unable to remap
C:\cygwin\lib\perl5\vendor_perl\5.8\cygwin\auto\Win32\Shortcut\Shortcut.
dll to same address as parent(0xBF0000) != 0x1110000
     13 [main] perl 3716 fork_parent: child 3088 died waiting for dll
loading

Here's an example that demonstrates the problem.

#!/usr/bin/perl -w
use strict;
use Win32::Shortcut;

if (my $pid= open (my $pipe, '-|')) {
  print "forked child process $pid\n";
  while (<$pipe>) { print "from child: $_"; }
  close ($pipe) or die;
} elsif (defined $pid) {
  print "this is the child\n";
  exit;
} else {
  print "fork failed: $!\n";
}

Without the "use Win32::Shortcut", the script runs fine. With the
package the fork fails with the error message I gave. Win32::Shortcut
works fine if I don't fork or don't do it until after the package is
loaded (eg. I can eval "require Win32::Shortcut" after the fork). I see
this behaviour with Perl 5.8.6 and 5.8.7 and Cygwin 1.5.17-1 and
1.5.18-1.

This error makes it a tricky to convert the Win32::Shortcut output to
Cygwin-style paths with cygpath -u (without resorting to a separate
program to parse the results). Or is there a Perl module that can do the
cygpath conversion? That would be even nicer!

Thanks,
Tim.

==============================  cut here  ==============================
Tim Adye, BaBar Group, Particle Physics Dept.,             _   /|
          Rutherford Appleton Laboratory, UK.              \'o.O'   Oop!
e-mail:   T.J.Adye@rl.ac.uk                                =(___)=  Ack!
WWW:      http://hepwww.rl.ac.uk/Delphi/Adye/homepage.html    U  Thphft!

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

Re: Perl Win32::Shortcut screws up fork

[Larry Hall]

At 01:10 PM 7/7/2005, you wrote:
>In an attempt to work round the problem with readshortcut I reported
>earlier, I thought I'd use a Perl script. Unfortunately the
>Win32::Shortcut package seems to cause problems with process forking
>(unlike the readshortcut error, this one isn't specific to the latest
>cygwin DLL). I get an error
>
>C:\cygwin\bin\perl.exe (3088): *** unable to remap
>C:\cygwin\lib\perl5\vendor_perl\5.8\cygwin\auto\Win32\Shortcut\Shortcut.
>dll to same address as parent(0xBF0000) != 0x1110000
>     13 [main] perl 3716 fork_parent: child 3088 died waiting for dll
>loading 


Sounds like a classic rebasing issue to me.  Have you tried running 
'rebaseall'?




--
Larry Hall                              http://www.rfk.com
RFK Partners, Inc.                      (508) 893-9779 - RFK Office
838 Washington Street                   (508) 893-9889 - FAX
Holliston, MA 01746                     


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

question for perl maintainer

[Christopher Faylor]

On Thu, Jul 07, 2005 at 02:08:40PM -0400, Larry Hall wrote:
>At 01:10 PM 7/7/2005, you wrote:
>>In an attempt to work round the problem with readshortcut I reported
>>earlier, I thought I'd use a Perl script. Unfortunately the
>>Win32::Shortcut package seems to cause problems with process forking
>>(unlike the readshortcut error, this one isn't specific to the latest
>>cygwin DLL). I get an error
>>
>>C:\cygwin\bin\perl.exe (3088): *** unable to remap
>>C:\cygwin\lib\perl5\vendor_perl\5.8\cygwin\auto\Win32\Shortcut\Shortcut.
>>dll to same address as parent(0xBF0000) != 0x1110000
>>     13 [main] perl 3716 fork_parent: child 3088 died waiting for dll
>>loading 
>
>Sounds like a classic rebasing issue to me.  Have you tried running
>'rebaseall'?

Wouldn't this problem be ameliorated slightly if the perl DLLs all
loaded in unique addresses to begin with?  Isn't the problem that all
perl DLLs (and probably others) are loading in address 0x10000000?

Gerrit, would you be willing to change this so that the DLLs load in
non-default locations?  This would probably help everyone right out
of the box?

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/

Re: question for perl maintainer

[Gerrit P. Haase]

Christopher Faylor wrote:

> On Thu, Jul 07, 2005 at 02:08:40PM -0400, Larry Hall wrote:
> 
>>At 01:10 PM 7/7/2005, you wrote:
>>
>>>In an attempt to work round the problem with readshortcut I reported
>>>earlier, I thought I'd use a Perl script. Unfortunately the
>>>Win32::Shortcut package seems to cause problems with process forking
>>>(unlike the readshortcut error, this one isn't specific to the latest
>>>cygwin DLL). I get an error
>>>
>>>C:\cygwin\bin\perl.exe (3088): *** unable to remap
>>>C:\cygwin\lib\perl5\vendor_perl\5.8\cygwin\auto\Win32\Shortcut\Shortcut.
>>>dll to same address as parent(0xBF0000) != 0x1110000
>>>    13 [main] perl 3716 fork_parent: child 3088 died waiting for dll
>>>loading 
>>
>>Sounds like a classic rebasing issue to me.  Have you tried running
>>'rebaseall'?
> 
> 
> Wouldn't this problem be ameliorated slightly if the perl DLLs all
> loaded in unique addresses to begin with?  Isn't the problem that all
> perl DLLs (and probably others) are loading in address 0x10000000?
> 
> Gerrit, would you be willing to change this so that the DLLs load in
> non-default locations?  This would probably help everyone right out
> of the box?

Sounds good.  WHat is the magic flag I need to add to the link commands?


Gerrit

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

Re: question for perl maintainer

[Gerrit P. Haase]

Gerrit P. Haase wrote:

>> Wouldn't this problem be ameliorated slightly if the perl DLLs all
>> loaded in unique addresses to begin with?  Isn't the problem that all
>> perl DLLs (and probably others) are loading in address 0x10000000?
>>
>> Gerrit, would you be willing to change this so that the DLLs load in
>> non-default locations?  This would probably help everyone right out
>> of the box?
> 
> 
> Sounds good.  WHat is the magic flag I need to add to the link commands?

Would --enable-auto-image-base do it or do I need to specify an address
with --image-base <address>?  If the second, which address may I use?

Gerrit


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

Re: question for perl maintainer

[Christopher Faylor]

On Thu, Jul 07, 2005 at 10:45:14PM +0200, Gerrit P. Haase wrote:
>Christopher Faylor wrote:
>
>>On Thu, Jul 07, 2005 at 02:08:40PM -0400, Larry Hall wrote:
>>
>>>At 01:10 PM 7/7/2005, you wrote:
>>>
>>>>In an attempt to work round the problem with readshortcut I reported
>>>>earlier, I thought I'd use a Perl script. Unfortunately the
>>>>Win32::Shortcut package seems to cause problems with process forking
>>>>(unlike the readshortcut error, this one isn't specific to the latest
>>>>cygwin DLL). I get an error
>>>>
>>>>C:\cygwin\bin\perl.exe (3088): *** unable to remap
>>>>C:\cygwin\lib\perl5\vendor_perl\5.8\cygwin\auto\Win32\Shortcut\Shortcut.
>>>>dll to same address as parent(0xBF0000) != 0x1110000
>>>>   13 [main] perl 3716 fork_parent: child 3088 died waiting for dll
>>>>loading 
>>>
>>>Sounds like a classic rebasing issue to me.  Have you tried running
>>>'rebaseall'?
>>
>>Wouldn't this problem be ameliorated slightly if the perl DLLs all
>>loaded in unique addresses to begin with?  Isn't the problem that all
>>perl DLLs (and probably others) are loading in address 0x10000000?
>>
>>Gerrit, would you be willing to change this so that the DLLs load in
>>non-default locations?  This would probably help everyone right out
>>of the box?
>
>Sounds good.  WHat is the magic flag I need to add to the link commands?

Something like -Wl,--image-base=0xsomething .

Or, you could just rebase the dlls prior to releasing perl, I guess.

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/

Re: question for perl maintainer

[Christopher Faylor]

On Thu, Jul 07, 2005 at 11:03:01PM +0200, Gerrit P. Haase wrote:
>Gerrit P. Haase wrote:
>
>>>Wouldn't this problem be ameliorated slightly if the perl DLLs all
>>>loaded in unique addresses to begin with?  Isn't the problem that all
>>>perl DLLs (and probably others) are loading in address 0x10000000?
>>>
>>>Gerrit, would you be willing to change this so that the DLLs load in
>>>non-default locations?  This would probably help everyone right out
>>>of the box?
>>
>>Sounds good.  WHat is the magic flag I need to add to the link commands?
>
>Would --enable-auto-image-base do it or do I need to specify an address
>with --image-base <address>?  If the second, which address may I use?

--enable-auto-image-base would probably be sufficient -- at least as a
first stab at fixing this problem.  Just make sure that none of the dlls
load into cygwin's load address.

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/

Re: question for perl maintainer

[Gerrit P. Haase]

Christopher Faylor wrote:

> --enable-auto-image-base would probably be sufficient -- at least as a
> first stab at fixing this problem.  Just make sure that none of the dlls
> load into cygwin's load address.

Can I tell the linker to exclude some address?


Gerrit

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

Re: question for perl maintainer

[Christopher Faylor]

On Fri, Jul 08, 2005 at 11:51:39AM +0200, Gerrit P. Haase wrote:
>Christopher Faylor wrote:
>>--enable-auto-image-base would probably be sufficient -- at least as a
>>first stab at fixing this problem.  Just make sure that none of the
>>dlls load into cygwin's load address.
>
>Can I tell the linker to exclude some address?

I don't think so but I don't think it will use cygwin's address anyway.

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/

Re: question for perl maintainer

[Gerrit P. Haase]

Christopher Faylor wrote:

> On Fri, Jul 08, 2005 at 11:51:39AM +0200, Gerrit P. Haase wrote:
> 
>>Christopher Faylor wrote:
>>
>>>--enable-auto-image-base would probably be sufficient -- at least as a
>>>first stab at fixing this problem.  Just make sure that none of the
>>>dlls load into cygwin's load address.
>>
>>Can I tell the linker to exclude some address?
> 
> 
> I don't think so but I don't think it will use cygwin's address anyway.


Ok.  Maybe Corinna should do the same for openssl?


Gerrit

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

Re: question for perl maintainer

[Corinna Vinschen]

On Jul  8 17:20, Gerrit P. Haase wrote:
> Christopher Faylor wrote:
> >I don't think so but I don't think it will use cygwin's address anyway.
> 
> Ok.  Maybe Corinna should do the same for openssl?

What? Why?  OpenSSL uses another base address already in the Makefile
(0x63000000).


Corinna

-- 
Corinna Vinschen                  Please, send mails regarding Cygwin to
Cygwin Project Co-Leader          mailto:cygwin@cygwin.com
Red Hat, Inc.

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

Re: question for perl maintainer

[Gerrit P. Haase]

Corinna Vinschen wrote:

> On Jul  8 17:20, Gerrit P. Haase wrote:
> 
>>Christopher Faylor wrote:
>>
>>>I don't think so but I don't think it will use cygwin's address anyway.
>>
>>Ok.  Maybe Corinna should do the same for openssl?
> 
> 
> What? Why?  OpenSSL uses another base address already in the Makefile
> (0x63000000).

Good thing.  I had problems using openssl extensions for MySQL and perl
together (half year back).  Is this a recent change or was it only perl
failing?


Gerrit

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

Re: question for perl maintainer

[Corinna Vinschen]

On Jul  8 19:46, Gerrit P. Haase wrote:
> Corinna Vinschen wrote:
> >What? Why?  OpenSSL uses another base address already in the Makefile
> >(0x63000000).
> 
> Good thing.  I had problems using openssl extensions for MySQL and perl
> together (half year back).  Is this a recent change or was it only perl
> failing?

OpenSSL 0.9.7 uses 0xFE000000 as base address.  For some reason which
is entirely beyond me, the OpenSSL developers chose 0x61000000 (OUCH!)
as base address for 0.9.8, which is especially funny because this base
address is *only* used for the Cygwin build.  I vetoed the address and
let it change to 0x63000000 for 0.9.8.


Corinna

-- 
Corinna Vinschen                  Please, send mails regarding Cygwin to
Cygwin Project Co-Leader          mailto:cygwin@cygwin.com
Red Hat, Inc.

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

Re: question for perl maintainer

[Jason Tishler]

Gerrit,

On Thu, Jul 07, 2005 at 11:03:01PM +0200, Gerrit P. Haase wrote:
> Gerrit P. Haase wrote:
> >Sounds good.  WHat is the magic flag I need to add to the link
> >commands?
> 
> Would --enable-auto-image-base do it or do I need to specify an address
> with --image-base <address>?  If the second, which address may I use?

FWIW, Cygwin Python has been using --enable-auto-image-base for about
five years now.  It avoids the need to rebase, but does not eliminate
it... :,(

Jason

-- 
PGP/GPG Key: http://www.tishler.net/jason/pubkey.asc or key servers
Fingerprint: 7A73 1405 7F2B E669 C19D  8784 1AFD E4CC ECF4 8EF6

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

Re: Observation for ALL maintainers who provide dlls (was Re: question for perl maintainer)

[Gerrit P. Haase]

>>Jason Tishler wrote:
>>
>>>>By the way, is it reliable to use objdump -x to find the base
>>>>(ImageBase) ?  For cygssl-0.9.8.dll it is 10000000, but I thought
>>>>the base was 0x63000000
>>>
>>>I use a command line like the following:
>>>
>>>   $ objdump -p /usr/bin/cygssl-0.9.7.dll | fgrep ImageBase
>>>   ImageBase               6c700000

I recently updated openssl (today):

$ objdump -p /usr/bin/cygssl-0.9.7.dll | fgrep ImageBase
ImageBase               10000000

$ objdump -p /usr/bin/cygssl-0.9.8.dll | fgrep ImageBase
ImageBase               10000000


I wonder how the reported ImageBase is 10000000 after Corinna
said that openssl uses 63000000.

What am I doing wrong?


Gerrit

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