From: LRN <lr...@gm...> - 2011-02-24 22:40:41
|
I'm trying to build perl 5.8.8 with msysgit patchset. Doing that with current msys (installed by mingw-get) leads to spectacular failure: XXXXXXX [main] miniperl YYYY sync_with_child: child ZZZZ(0xNNN) died before initialization with status code 0xC0000135 Rebasing msys with rebaseall (from dash) does not help. However, jon_y told me that he was able to build 5.8.8 with exactly that patchset without such problems, didn't even have to rebase. I've tried to do the build on Win7 x64, clean Win7 x64, WinXP Pro x86 running in VBox, WinXP Pro x86 running natively. All 4 have failed with the same error. Which led me to the conclusion that something is wrong with my tools, not with the environment. I've managed to manually put together an old msys installation from the packages dating between 2001 and 2008 (jon_y built his perl somewhere in Dec 2008), tried again - and succeeded (well, i've had some glitches along the way, but nothing that can't be patched). I have not tried to build perl 5.6.1 with current msys, but i assume that it builds successfully (otherwise you would have noticed, it was packaged in Jan 2010). I'm not sure where the problem lies, but it's something to consider, if you are planning to ever update perl. |
From: Charles W. <cwi...@us...> - 2011-02-24 23:03:16
|
On 2/24/2011 5:40 PM, LRN wrote: > I'm trying to build perl 5.8.8 with msysgit patchset. > Doing that with current msys (installed by mingw-get) leads to > spectacular failure: > XXXXXXX [main] miniperl YYYY sync_with_child: child ZZZZ(0xNNN) died > before initialization with status code 0xC0000135 > Rebasing msys with rebaseall (from dash) does not help. I had exactly the same problem. Haven't tried again since maybe last September. > However, jon_y told me that he was able to build 5.8.8 with exactly that > patchset without such problems, didn't even have to rebase. > I've tried to do the build on Win7 x64, clean Win7 x64, WinXP Pro x86 > running in VBox, WinXP Pro x86 running natively. All 4 have failed with > the same error. Which led me to the conclusion that something is wrong > with my tools, not with the environment. Well, if so then I share the same problem. It may be that jon_y's build environment (which IIRC is the msys-phoenix build, which is a rather old semi-fork of our msys) is, for whatever reason, "better" about this problem than the current official msys 1.0.16. I've been meaning to look into this a bit more, but time is short. Family/medical... > I've managed to manually put together an old msys installation from the > packages dating between 2001 and 2008 (jon_y built his perl somewhere in > Dec 2008), tried again - and succeeded (well, i've had some glitches > along the way, but nothing that can't be patched). Yep, sounds like some of the improvements in "our" msys have increased the prevalence of the dreaded sync_with_child problem. Cygwin has also experienced growing pains of this sort... > I have not tried to build perl 5.6.1 with current msys, but i assume > that it builds successfully (otherwise you would have noticed, it was > packaged in Jan 2010). I'm not sure where the problem lies, but it's > something to consider, if you are planning to ever update perl. This is all good information; thanks for investigating. I'm probably going to have to dig in to some old cygwin-dev threads and figure out how to change msys itself to beat this problems back. Sigh. -- Chuck |
From: JonY <jo...@us...> - 2011-02-24 23:44:45
Attachments:
0xED74C077.asc
|
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 2/25/2011 07:03, Charles Wilson wrote: > On 2/24/2011 5:40 PM, LRN wrote: >> I'm trying to build perl 5.8.8 with msysgit patchset. >> Doing that with current msys (installed by mingw-get) leads to >> spectacular failure: >> XXXXXXX [main] miniperl YYYY sync_with_child: child ZZZZ(0xNNN) died >> before initialization with status code 0xC0000135 >> Rebasing msys with rebaseall (from dash) does not help. > > I had exactly the same problem. Haven't tried again since maybe last > September. > >> However, jon_y told me that he was able to build 5.8.8 with exactly that >> patchset without such problems, didn't even have to rebase. >> I've tried to do the build on Win7 x64, clean Win7 x64, WinXP Pro x86 >> running in VBox, WinXP Pro x86 running natively. All 4 have failed with >> the same error. Which led me to the conclusion that something is wrong >> with my tools, not with the environment. > > Well, if so then I share the same problem. It may be that jon_y's build > environment (which IIRC is the msys-phoenix build, which is a rather old > semi-fork of our msys) is, for whatever reason, "better" about this > problem than the current official msys 1.0.16. > I was using vanilla MSYS then in 2008, not phoenix. It was all done on a Vista32 machine, no segfaults, no errors, it just worked out of the box. I remember using msysgit patches and msys-dtk, along with all the msys libs like libcrypt and such. >> I've managed to manually put together an old msys installation from the >> packages dating between 2001 and 2008 (jon_y built his perl somewhere in >> Dec 2008), tried again - and succeeded (well, i've had some glitches >> along the way, but nothing that can't be patched). > > Yep, sounds like some of the improvements in "our" msys have increased > the prevalence of the dreaded sync_with_child problem. Cygwin has also > experienced growing pains of this sort... > I think I stayed back at 1.0.10 or 1.0.11 because I was getting problems with the newer builds at the time. I haven't really been using MSYS since switching to Cygwin. -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.16 (MingW32) iEYEARECAAYFAk1m7V8ACgkQp56AKe10wHf0UACfXWrF6aufIlyAnCPzsa1kFYMA G+EAn0byBY3NOiJ1ZEEG3m4QCJnJVDyC =Qy32 -----END PGP SIGNATURE----- |
From: Charles W. <cwi...@us...> - 2011-02-25 00:09:55
|
On 2/24/2011 6:44 PM, JonY wrote: > On 2/25/2011 07:03, Charles Wilson wrote: >> Well, if so then I share the same problem. It may be that jon_y's build >> environment (which IIRC is the msys-phoenix build, which is a rather old >> semi-fork of our msys) is, for whatever reason, "better" about this >> problem than the current official msys 1.0.16. > > > I was using vanilla MSYS then in 2008, not phoenix. It was all done on a > Vista32 machine, no segfaults, no errors, it just worked out of the box. > > I remember using msysgit patches and msys-dtk, along with all the msys > libs like libcrypt and such. Interesting. Another idea I just had off the top of my head was PERHAPS the problem is related to the new msys-gcc (3.4.5 vs. 2.95) and/or DLLs introduced since 2008. The whole sync_with_child problem is usually triggered because some DLL didn't end up loaded with the same image_base address in the child as it had in the parent. In the "new" msys (e.g. since summer 2009) we have a LOT more .dll's running around. Also, libintl is (a) much newer, and (b) linked as a dll instead of statically. So each perl process now has /THAT/ dll to load, which it did not previously -- plus all the rest. All of these changes to the basic msysDVLPR environment happened around summer 2009 with a second phase in spring 2010...in fact, is was only in early 2010 that I actually found it necessary to even bother porting rebase.exe, rebaseall, and dash.exe to msys! I wonder, if I just try to force perl-5.8.8 to link statically against its deps, rather than dynamically...oh, wait, that would mean libtool would croak when creating the *perl* DLLs and extension libs. (does perl build use libtool? can't recall...) >> Yep, sounds like some of the improvements in "our" msys have increased >> the prevalence of the dreaded sync_with_child problem. Cygwin has also >> experienced growing pains of this sort... > > > I think I stayed back at 1.0.10 or 1.0.11 because I was getting problems > with the newer builds at the time. I haven't really been using MSYS > since switching to Cygwin. Ack. The i18n support in new cygwin is very nice, plus the simple fact that they have a more active and larger core dev team, plus more users, means more eyes to find (and squash!) bugs. Plus, they've already gone thru a lot of the teething issues related to oodles of DLLs + sync_with_child (although it still crops up, in another guise, occasionally). This is where I start daydreaming about msys-2.0 based on cygwin-1.7 (giving up on win9x support, but enabling us to more closely track upstream cygwin in the future [*])...oh well. Part of my problem is I no longer use mingw gcc for the day job, so less /personal/ impetus to dive in... [*] Also, as cygwin adds more features, upstream projects start removing #ifdef __CYGWIN__ workarounds (openssl & openssh, fer instance) which we then have to add back in for __MSYS__, instead of simply cheating and #defining __CYGWIN__ to piggyback. OR upstream starts requiring those new features for __CYGWIN__ -- even I'm guilty: http://lists.gnu.org/archive/html/bug-gnulib/2011-01/msg00522.html "The only likely complaints might come from the MSYS project, since they are based on cygwin-1.3.4, but...since they deliberately operate in a closed garden they -- by which I mean "me" -- will just have to deal with it." -- Chuck |
From: LRN <lr...@gm...> - 2011-02-25 00:41:39
|
On 25.02.2011 3:09, Charles Wilson wrote: > I wonder, if I just try to force perl-5.8.8 to link statically against > its deps, rather than dynamically...oh, wait, that would mean libtool > would croak when creating the *perl* DLLs and extension libs. (does perl > build use libtool? can't recall...) It does not use libtool. |
From: LRN <lr...@gm...> - 2011-02-25 14:54:20
|
On 25.02.2011 3:09, Charles Wilson wrote: > On 2/24/2011 6:44 PM, JonY wrote: >> On 2/25/2011 07:03, Charles Wilson wrote: >>> Well, if so then I share the same problem. It may be that jon_y's build >>> environment (which IIRC is the msys-phoenix build, which is a rather old >>> semi-fork of our msys) is, for whatever reason, "better" about this >>> problem than the current official msys 1.0.16. >> >> I was using vanilla MSYS then in 2008, not phoenix. It was all done on a >> Vista32 machine, no segfaults, no errors, it just worked out of the box. >> >> I remember using msysgit patches and msys-dtk, along with all the msys >> libs like libcrypt and such. > Interesting. > > Another idea I just had off the top of my head was PERHAPS the problem > is related to the new msys-gcc (3.4.5 vs. 2.95) and/or DLLs introduced > since 2008. The whole sync_with_child problem is usually triggered > because some DLL didn't end up loaded with the same image_base address > in the child as it had in the parent. I've attempted to unpack gcc-3.4.4-3-msys-1.0.13-bin.tar.lzma on top of the msys installation with which i've built perl, and then use that msys, with new gcc, to build perl again. The error reappeared. This gives weight to your theory about blaming it on gcc 3.4.x. |
From: LRN <lr...@gm...> - 2011-02-25 18:04:29
Attachments:
testlog.xz
|
On 25.02.2011 17:53, LRN wrote: > On 25.02.2011 3:09, Charles Wilson wrote: >> On 2/24/2011 6:44 PM, JonY wrote: >>> On 2/25/2011 07:03, Charles Wilson wrote: >>>> Well, if so then I share the same problem. It may be that jon_y's >>>> build >>>> environment (which IIRC is the msys-phoenix build, which is a >>>> rather old >>>> semi-fork of our msys) is, for whatever reason, "better" about this >>>> problem than the current official msys 1.0.16. >>> >>> I was using vanilla MSYS then in 2008, not phoenix. It was all done >>> on a >>> Vista32 machine, no segfaults, no errors, it just worked out of the >>> box. >>> >>> I remember using msysgit patches and msys-dtk, along with all the msys >>> libs like libcrypt and such. >> Interesting. >> >> Another idea I just had off the top of my head was PERHAPS the problem >> is related to the new msys-gcc (3.4.5 vs. 2.95) and/or DLLs introduced >> since 2008. The whole sync_with_child problem is usually triggered >> because some DLL didn't end up loaded with the same image_base address >> in the child as it had in the parent. > I've attempted to unpack gcc-3.4.4-3-msys-1.0.13-bin.tar.lzma on top > of the msys installation with which i've built perl, and then use that > msys, with new gcc, to build perl again. The error reappeared. This > gives weight to your theory about blaming it on gcc 3.4.x. Also, retrofitting modern msys with msysDVLPR-1.0.0-alpha-1.tar.gz allowed me to build perl 5.8.8 without stumbling upon fork-related errors. Well, i wouldn't say that i've had no errors during the build, some extensions have failed to build and make ignored them. But that's better than encountering "sync_with_child" error early. Also note that "build perl" does not mean "build perl that passes all tests" or "get a build of perl that works flawlessly". Attached to this message is a compressed log from executing `make test' upon the latest version of perl i've built (the one when i've used modern msys retrofitted with gcc-2.95). Looks decent to me, but then i have only rudimentary knowledge of perl and i am hardly capable of judging the importance of the failed testcases. |
From: LRN <lr...@gm...> - 2011-02-25 23:44:27
|
On 25.02.2011 21:04, LRN wrote: > On 25.02.2011 17:53, LRN wrote: >> On 25.02.2011 3:09, Charles Wilson wrote: >>> On 2/24/2011 6:44 PM, JonY wrote: >>>> On 2/25/2011 07:03, Charles Wilson wrote: >>>>> Well, if so then I share the same problem. It may be that jon_y's >>>>> build >>>>> environment (which IIRC is the msys-phoenix build, which is a >>>>> rather old >>>>> semi-fork of our msys) is, for whatever reason, "better" about this >>>>> problem than the current official msys 1.0.16. >>>> >>>> I was using vanilla MSYS then in 2008, not phoenix. It was all done >>>> on a >>>> Vista32 machine, no segfaults, no errors, it just worked out of the >>>> box. >>>> >>>> I remember using msysgit patches and msys-dtk, along with all the msys >>>> libs like libcrypt and such. >>> Interesting. >>> >>> Another idea I just had off the top of my head was PERHAPS the problem >>> is related to the new msys-gcc (3.4.5 vs. 2.95) and/or DLLs introduced >>> since 2008. The whole sync_with_child problem is usually triggered >>> because some DLL didn't end up loaded with the same image_base address >>> in the child as it had in the parent. >> I've attempted to unpack gcc-3.4.4-3-msys-1.0.13-bin.tar.lzma on top >> of the msys installation with which i've built perl, and then use >> that msys, with new gcc, to build perl again. The error reappeared. >> This gives weight to your theory about blaming it on gcc 3.4.x. > Also, retrofitting modern msys with msysDVLPR-1.0.0-alpha-1.tar.gz > allowed me to build perl 5.8.8 without stumbling upon fork-related > errors. > > Well, i wouldn't say that i've had no errors during the build, some > extensions have failed to build and make ignored them. But that's > better than encountering "sync_with_child" error early. > Also note that "build perl" does not mean "build perl that passes all > tests" or "get a build of perl that works flawlessly". Attached to > this message is a compressed log from executing `make test' upon the > latest version of perl i've built (the one when i've used modern msys > retrofitted with gcc-2.95). Looks decent to me, but then i have only > rudimentary knowledge of perl and i am hardly capable of judging the > importance of the failed testcases. Well, i've been tinkering around with the buildscript, and it came out pretty well. I'm attaching compressed test and harness logs and the buildsystem to this message. Requires contemporary msys with msysDVLPR-1.0.0-alpha-1.tar.gz H-m-m... Could it be possible to just download msysDVLPR (the same way it downloads perl tarball), unpack it to a local directory and prepend that directory's bin subdir to the PATH (msys-build-perl already changes PATH, so it shouldn't be a problem)? That would allow current msys users to build this perl OOTB with this buildscript, and will allow msys-perl-5.8.8 to become a full-featured package (as long as msysDVLPR dependency is not considered too ugly, or maybe you can just make a package for msys-gcc-2.95.3). P.S. It skips the installation of man-pages for some reason. |
From: Charles W. <cwi...@us...> - 2011-02-26 14:27:08
|
On 2/25/2011 6:44 PM, LRN wrote: > On 25.02.2011 21:04, LRN wrote: >> Also, retrofitting modern msys with msysDVLPR-1.0.0-alpha-1.tar.gz >> allowed me to build perl 5.8.8 without stumbling upon fork-related >> errors. >> > Well, i've been tinkering around with the buildscript, and it came out > pretty well. I'm attaching compressed test and harness logs and the > buildsystem to this message. > Requires contemporary msys with msysDVLPR-1.0.0-alpha-1.tar.gz > H-m-m... Could it be possible to just download msysDVLPR (the same way > it downloads perl tarball), unpack it to a local directory and prepend > that directory's bin subdir to the PATH (msys-build-perl already changes > PATH, so it shouldn't be a problem)? That would allow current msys users > to build this perl OOTB with this buildscript, and will allow > msys-perl-5.8.8 to become a full-featured package (as long as msysDVLPR > dependency is not considered too ugly, or maybe you can just make a > package for msys-gcc-2.95.3). No, these alternatives won't do what you expect. GCC (other than the special MinGW version) hardcodes some paths for header and library inclusion: /usr/[lib|include] for instance. If you mis-install gcc-2.95.3 into /opt/old-gcc/, it will STILL look in /usr/include FIRST for some headers -- including some that are specifically tied to the gcc implementation. Thus, you'd mix gcc-3.x headers with the gcc-2.95 compiler...bad. Also, there was an ABI change between gcc-2.95 and gcc-3.x -- which means you really shouldn't mix libraries/DLLs compiled using one, with apps compiled using the other. Thus, notwithstanding your success, you're ASKING for trouble when overlaying the gcc-2.95.3 compiler on top of a "modern" MSYS in which all the libs/DLLs were compiled using gcc-3. So, unfortunately, your solution can't be used in general. What's interesting is that the OLD perl (5.6.1) could be compiled using gcc-3 without these issues. So, it's not just the GCC update that causes the problem -- it's the combination of updating BOTH gcc and perl. Solving this problem is not going to be easy. :-( > P.S. It skips the installation of man-pages for some reason. You have to explicitly install the man pages; perl's Makefile doesn't do it automatically. FYI, here's some info concerning the current perl. Note the last bullet: ---------- perl-5.6.1_2-2 -- 2010 Jan 30 ----------- * Rebuild against msys-1.0.13, using (msys)gcc-3.4.4 and (msys)binutils-2.19.51. * Link against new (separate) gdbm and gdbm-compat libraries * Link against (static) libiconv * Build with -DDEBUGGING -- but symbols are stripped; this allows printing internal state within perl itself, but doesn't allow using gdb. This is a compromise for size (besides, gdb-based debugging at -O2 is not very useful). * Use -O2 -fno-unit-at-a-time to avoid optimization bug in latest msys-gcc. Also, don't use -mms-bitfields. -- Chuck |
From: Charles W. <cwi...@us...> - 2011-02-26 15:25:46
|
BTW, I've done some digging in the cygwin archives and ran across this thread: http://cygwin.com/ml/cygwin/2003-04/msg00461.html "I get something along the lines of "failed to sync with child"...I had to revert back to 5.6.1" At the time, Nicholas supposed the issue was with Win9x OS's + a change in the perl stack size, but I think he was wrong about that. In any case, this issue was encountered during *cygwin's* transition from perl-5.6.x to perl-5.8.x -- which is exactly the transition we are attempting -- so I'll keep looking. -- Chuck |
From: LRN <lr...@gm...> - 2011-02-26 22:09:34
|
On 26.02.2011 17:26, Charles Wilson wrote: > Also, there was an ABI change between gcc-2.95 and gcc-3.x -- which > means you really shouldn't mix libraries/DLLs compiled using one, with > apps compiled using the other. Thus, notwithstanding your success, > you're ASKING for trouble when overlaying the gcc-2.95.3 compiler on > top of a "modern" MSYS in which all the libs/DLLs were compiled using > gcc-3. So, unfortunately, your solution can't be used in general. perl only links to libmsys-1.0.dll. Would it be possible to keep a version of that library, compiled with the ancient gcc, under a different name, and link perl to it? > What's interesting is that the OLD perl (5.6.1) could be compiled > using gcc-3 without these issues. So, it's not just the GCC update > that causes the problem -- it's the combination of updating BOTH gcc > and perl. Solving this problem is not going to be easy. :-( The change that triggers this bug was introduced between perl 5.7.2 and 5.7.3 (5.7.2 builds, 5.7.3 does not). >> P.S. It skips the installation of man-pages for some reason. > You have to explicitly install the man pages; perl's Makefile doesn't do > it automatically. No, actually it was looking for nroff. If it isn't found, the configure script disables makefile installation. > > > FYI, here's some info concerning the current perl. Note the last bullet: > > * Use -O2 -fno-unit-at-a-time to avoid optimization bug > in latest msys-gcc. Also, don't use -mms-bitfields. -fno-unit-at-a-time has no effect on the bug. |
From: LRN <lr...@gm...> - 2011-02-27 01:04:13
Attachments:
baddiff
|
On 27.02.2011 1:09, LRN wrote: > >> What's interesting is that the OLD perl (5.6.1) could be compiled >> using gcc-3 without these issues. So, it's not just the GCC update >> that causes the problem -- it's the combination of updating BOTH gcc >> and perl. Solving this problem is not going to be easy. :-( > The change that triggers this bug was introduced between perl 5.7.2 > and 5.7.3 (5.7.2 builds, 5.7.3 does not). git bisect told me this: ------------------- 619685113277299f7d5ceee4658212496ca713ad is the first bad commit commit 619685113277299f7d5ceee4658212496ca713ad Author: Gisle Aas <gi...@aa...> Date: Tue Dec 11 12:52:57 2001 -0800 Passing in env to perl_parse did not work Message-ID: <lrh...@ca...> p4raw-id: //depot/perl@13660 :100644 100644 e1d3d18e1cc2967aa69dc08644db7f867570161d cd82fe2ff570994b8b4e43c1cbada44f6b36a516 M perl.c :100644 100644 5782b71b6ba33ffd4c17f266ce5c658c7db4d320 d25ffd7f22c42aee23e0b47da16e3d324b8ca39b M perl.h ------------------- Attached are the changes this commit introduces. Removing "#define USE_ENVIRON_ARRAY" from unixish.h or commenting out the "if (env != environ) mg_set(sv);" part in perl.c appears to solve the problem. However i do not understand how this code is able to trigger the bug. |
From: Charles W. <cwi...@us...> - 2011-02-27 03:46:43
Attachments:
perl.c.diff
|
On 2/26/2011 8:03 PM, LRN wrote: > On 27.02.2011 1:09, LRN wrote: >> The change that triggers this bug was introduced between perl 5.7.2 >> and 5.7.3 (5.7.2 builds, 5.7.3 does not). > git bisect told me this: > ------------------- > 619685113277299f7d5ceee4658212496ca713ad is the first bad commit > commit 619685113277299f7d5ceee4658212496ca713ad > Author: Gisle Aas <gis...@pu...> > Date: Tue Dec 11 12:52:57 2001 -0800 > > Passing in env to perl_parse did not work > Message-ID: > <lrh...@pu...> Here's the discussion and rationale: http://www.nntp.perl.org/group/perl.perl5.porters/2001/12/msg48851.html As you can see, NOT calling mg_set() is bad juju, because it is only by calling mg_set() that perl's idea of the environment is updated to contain anything inherited from the "real" _environ variable OR even from the *envp passed in via execle(). > Attached are the changes this commit introduces. > > Removing "#define USE_ENVIRON_ARRAY" from unixish.h or commenting out > the "if (env != environ) mg_set(sv);" part in perl.c appears to solve > the problem. However i do not understand how this code is able to > trigger the bug. Well, here's my guess: 1) passing an env array to a child process is pretty common 2) mucking about WITH that array, prior to fork(), can cause a change in the memory layout of that array or the elements that it points to. 3) This maybe could cause a mismatch in the parent/child memory layout. 4) bang, sync_with_child error. In addition, there is ANOTHER issue related to *env, on win32 and cygwin. On win32, _environ is special: http://msdn.microsoft.com/en-us/library/stxk41x1.aspx However, cygwin/msys actually maintains MULTIPLE COPIES of the environment (especially in multithreaded situations, AND IN multiple DLLs). There's this internal cygwin function: update_envptrs (); /* Update any local copies of 'environ'. */ which is called by the core worker function that setenv/putenv/setenv_r and friends all use. It's part of dll_init.cc, and here's the body: /* Called from various places to update all of the individual ideas of the environ block. Explain to me again why we didn't just import __cygwin_environ? */ void __stdcall update_envptrs () { for (dll *d = dlls.istart (DLL_ANY); d; d = dlls.inext ()) *(d->p.envptr) = __cygwin_environ; *main_environ = __cygwin_environ; } It updates a structure for EACH DLL loaded in the current process, to point to the (possibly reallocated, and thus moved) __cygwin_environment. So there are two things that can go wrong if you manipulate the env pointer or its contents directly: a) you try to write a string into a slot that is longer than the amount of memory allocated for that slot. Eg. buffer overrun, and something gets clobbered. b) you update one copy of the environ by modifying it directly, but...the other internal copies don't get updated. E.g. different threads access different (freed?) pointers, or even in the SAME thread, code from ONE DLL thinks the environment is --> over there, but code from a different DLL thinks it is <-- over here. Bad bad juju. Answer: don't muck with environ. Instead, use setenv/putenv if you want to make changes to the environment. I have a hunch that setting environ (e.g. environ = my_new_array; doesn't really work like one would hope on cygwin. This is why we use -DPERL_USE_SAFE_PUTENV when building perl -- so that it uses setenv/unsetenv (oddly, not putenv) when PERL wants to modify the environment rather than "manipulating environ directly". But then, there's this code you've located in perl.c which does JUST THAT: as patched, it DOES manipulate environ directly. I *think* this might be okay, as it is in the main entry function for the interpreter (e.g. a main()-ish function that takes argc, argv, envp) so we probably have only one thread at that point. We DO, however, have multiple DLLs loaded, tho. :-( However, if you undefine USE_ENVIRON_ARRAY, then you can't do ANY putenv/setenv/unsetenv from perl! (This, I think, is a thinko if you look closely at util.c, but fixing it would be somewhat awkward). So...one workaround here is to sorta re-integrate SOME of the stuff this commit removed, and #define NEED_ENVIRON_DUP_FOR_MODIFY for CYGWIN/MSYS. However, there's already a bug: for (; *env; env++) { ... if (env != environ) mg_set(sv); ... } Only the FIRST time thru the loop could env possibly be == environ. So, why don't you try this: replace ALL this code with what is in git HEAD. It actually seems to make more sense to me, and avoids mucking around too much with the environ variable directly. patch attached... Last Q, I don't know if this bit (which is still in the code) works like we think: if (env_is_not_environ ... ) { environ[0] = NULL; } Because it will only affect the copy of environ in THIS DLL (that is, msys-perl5_8.dll) and not in any other DLLs. However, because external DLLs probably don't CARE what perl did to environ, and perl XS extension DLLs don't access environ directly anyway (they use the perl functions to get msys-perl5_8.dll's version of the environment) I guess that should be okay. Anyway, give the attached patch a shot... -- Chuck |
From: LRN <lr...@gm...> - 2011-02-27 03:58:25
|
On 27.02.2011 6:46, Charles Wilson wrote: >>>> P.S. It skips the installation of man-pages for some reason. >>> You have to explicitly install the man pages; perl's Makefile doesn't do >>> it automatically. >> No, actually it was looking for nroff. If it isn't found, the configure >> script disables makefile installation. > Ah. Well, even if you DID have nroff (msys-groff), you wouldn't have > installed the man pages via 'make install' -- you have to do 'make > install.man' or something. That's how it was in perl-5.6.1 In newer perls `make install' seems to work properly (though i didn't check THAT particular fact thoroughly, so i might be wrong) > So, why don't you try this: replace ALL this code with what is in git > HEAD. It actually seems to make more sense to me, and avoids mucking > around too much with the environ variable directly. > > patch attached... > > Last Q, I don't know if this bit (which is still in the code) works like > we think: > > if (env_is_not_environ > ... > ) > { > environ[0] = NULL; > } > > Because it will only affect the copy of environ in THIS DLL (that is, > msys-perl5_8.dll) and not in any other DLLs. However, because external > DLLs probably don't CARE what perl did to environ, and perl XS extension > DLLs don't access environ directly anyway (they use the perl functions > to get msys-perl5_8.dll's version of the environment) I guess that > should be okay. > > Anyway, give the attached patch a shot... Actually, i'm trying to build perl 5.12.3 at the moment. I'll give your patch a try if that fails. |
From: LRN <lr...@gm...> - 2011-02-27 14:17:19
|
On 27.02.2011 6:57, LRN wrote: > Actually, i'm trying to build perl 5.12.3 at the moment. I'll give > your patch a try if that fails. 5.12.3 builds! \o/ Testsuite is still unpatched, and i'm currently fixing the installation/packaging procedure (i think it's worth a try to attempt to use DESTDIR once again), but 5.12.3 builds without triggering sync_with_child bug. |
From: Charles W. <cwi...@us...> - 2011-02-27 19:02:54
|
On 2/27/2011 9:16 AM, LRN wrote: > On 27.02.2011 6:57, LRN wrote: >> Actually, i'm trying to build perl 5.12.3 at the moment. I'll give >> your patch a try if that fails. > 5.12.3 builds! \o/ > Testsuite is still unpatched, and i'm currently fixing the > installation/packaging procedure (i think it's worth a try to attempt to > use DESTDIR once again), but 5.12.3 builds without triggering > sync_with_child bug. Well, that's tremendously awesome. While not /proving/ the point, it doesn't DISprove the assertion that replacing the gunk in perl.c with something more modern may ALSO fix the issue. Fortunately Reini Urban (cygwin's perl maintainer) has been very active @ perl.org pushing cygwin fixes into the code: http://blogs.perl.org/users/rurban/2010/05/cdynalib-progress.html http://groups.google.com/group/perl.perl5.porters/msg/0087cc90c39f063c Yesterday: !!! http://www.gossamer-threads.com/lists/perl/porters/261230?page=last etc... so, we may be okay "rushing ahead of cygwin" in this manner. See, in the past perl required so much TLC just to get working on cygwin -- I know, I was part of some of the initial (re)porting efforts vs. cygwin-B20.1 back in the mid-90's -- that on MSYS, it has long been considered the better part of valor to let them go first, and just piggy back on whatever they ship. By moving to 5.12 while they are still on 5.10, we can't do that. (Don't bother trying to make cygwin's 5.10 work on msys; I did; it doesn't). But...as I said, perhaps that's ok NOW vis 5.12 given Reini's recent efforts. If you get anything close to decent testsuite performance, I'll look into adopting some of the current cygwin patches/packaging in order to bundle some extensions (e.g. so that end users can, at least, then use CPAN for additional customizations). Of course, cygwin perl is still at 5.10.3... In any case, we might also need to bring in Reini's 'perlrebase' tool, which is a script like rebaseall, but invokes rebase.exe only on perl DLLs with some special settings for perl. -- Chuck |
From: LRN <lr...@gm...> - 2011-02-28 03:45:40
|
On 27.02.2011 22:02, Charles Wilson wrote: > On 2/27/2011 9:16 AM, LRN wrote: >> On 27.02.2011 6:57, LRN wrote: >>> Actually, i'm trying to build perl 5.12.3 at the moment. I'll give >>> your patch a try if that fails. >> 5.12.3 builds! \o/ >> Testsuite is still unpatched, and i'm currently fixing the >> installation/packaging procedure (i think it's worth a try to attempt to >> use DESTDIR once again), but 5.12.3 builds without triggering >> sync_with_child bug. > If you get anything close to decent testsuite performance, I'll look > into adopting some of the current cygwin patches/packaging in order to > bundle some extensions (e.g. so that end users can, at least, then use > CPAN for additional customizations). Of course, cygwin perl is still at > 5.10.3... Here ( http://lrn.no-ip.info/other/mingw/experimental-msys-perl/ ) are my buildscript (with patches) and logs of the build (also, diffs between initial unpatched testsuite output and the output of two patched versions of it). This ML only allows attachments up to 140Kb, so you'd have to download the files from my webserver. > In any case, we might also need to bring in Reini's 'perlrebase' tool, > which is a script like rebaseall, but invokes rebase.exe only on perl > DLLs with some special settings for perl. Most certainly. I hope that rebasing perl after building it will prevent the testsuite from failing so much. |
From: Charles W. <cwi...@us...> - 2011-02-28 05:54:05
|
On 2/27/2011 10:45 PM, LRN wrote: > Here ( http://lrn.no-ip.info/other/mingw/experimental-msys-perl/ ) are > my buildscript (with patches) and logs of the build (also, diffs between > initial unpatched testsuite output and the output of two patched > versions of it). This ML only allows attachments up to 140Kb, so you'd > have to download the files from my webserver. OK, I'll take a look -- but I'm going to be busy for a few days so it'll probably be Thu at the earliest... -- Chuck |
From: LRN <lr...@gm...> - 2011-03-01 15:51:52
|
On 27.02.2011 22:02, Charles Wilson wrote: > In any case, we might also need to bring in Reini's 'perlrebase' tool, > which is a script like rebaseall, but invokes rebase.exe only on perl > DLLs with some special settings for perl. > About rebase. I've studied its source package and have found that rebase can be built natively, i.e. made link against msvcrt rather than msys-1.0 This native rebase coupled with a program (also native) that does the same thing rebaseall script does (composes a list of files by recursively looking through directories for files ending with some prefixes and then invokes rebase), allows rebasing to be done outside of bash/dash or whatever and would make rebasing more complete. It could be also run automatically - simply make a batch file that waits a few seconds, kills any msys processes still running, runs rebase, re-runs msys-sh, making it run a particular script (which is written beforehand) that will restore the shell state (set env variables, cd into the right directory and run the right command, probably `make $something'). With such a tool it should be possible to rebase perl after it is compiled and before its testsuite is run - and all that would be completely automatic! |
From: LRN <lr...@gm...> - 2011-03-02 05:06:17
Attachments:
rebase-3.0.1_1-3-mingw32-1.0.15-src.tar.lzma
|
On 01.03.2011 18:51, LRN wrote: > On 27.02.2011 22:02, Charles Wilson wrote: >> In any case, we might also need to bring in Reini's 'perlrebase' tool, >> which is a script like rebaseall, but invokes rebase.exe only on perl >> DLLs with some special settings for perl. >> > About rebase. I've studied its source package and have found that > rebase can be built natively, i.e. made link against msvcrt rather > than msys-1.0 > This native rebase coupled with a program (also native) that does the > same thing rebaseall script does (composes a list of files by > recursively looking through directories for files ending with some > prefixes and then invokes rebase), allows rebasing to be done outside > of bash/dash or whatever and would make rebasing more complete. It > could be also run automatically - simply make a batch file that waits > a few seconds, kills any msys processes still running, runs rebase, > re-runs msys-sh, making it run a particular script (which is written > beforehand) that will restore the shell state (set env variables, cd > into the right directory and run the right command, probably `make > $something'). > With such a tool it should be possible to rebase perl after it is > compiled and before its testsuite is run - and all that would be > completely automatic! Something like this (attached). Works as expected (although rebasing my perl 5.12.3 port does not seem to improve its test-time performance, so it must be just broken). |
From: Charles W. <cwi...@us...> - 2011-03-02 16:36:13
|
On 3/1/2011 10:51 AM, LRN wrote: > On 27.02.2011 22:02, Charles Wilson wrote: >> In any case, we might also need to bring in Reini's 'perlrebase' tool, >> which is a script like rebaseall, but invokes rebase.exe only on perl >> DLLs with some special settings for perl. >> > About rebase. I've studied its source package and have found that rebase > can be built natively, i.e. made link against msvcrt rather than msys-1.0 > This native rebase coupled with a program (also native) that does the > same thing rebaseall script does (composes a list of files by > recursively looking through directories for files ending with some > prefixes and then invokes rebase), allows rebasing to be done outside of > bash/dash or whatever and would make rebasing more complete. This is all true, and would be useful -- but it's /kinda/ beside the point re: perl. See, all of the above helps if you want to do a FULL (Msys) system rebase: rebasing all DLLs in the entire MSYS (and MinGW?) tree. This has to do with the fact that you can't rebase an in-use DLL, and since almost every .exe (including bash, and the coreutils utilities) use SOME dlls like libiconv or libintl, then THOSE particular DLLs can't be rebased if you try to run the app (or script) from within a bash shell. Note that we do not rebase the msys DLL during 'rebaseall' -- it is specifically excluded. The msys DLL is compiled with a specific image base address that is outside the range of addresses used by rebaseall when rebasing the OTHER dlls on the system, so in this way we can hope that the msys dll won't have a clashing image base addr anyway. *perlrebase*, on the other hand, is a shell script that ONLY rebases the dlls associated with perl, including extension XS dlls. It also uses an address range different than that used by rebaseall for the /rest/ of the DLLs on the system -- this way, the two sets of DLLs will be unlikely to have image base addresses that clash. However, since perlrebase is a shell script, and doesn't use any perl commands, one can hope that perl is not loaded into memory, and hence: the DLLs associated with perl will all be rebase-able (e.g. not in use). So...for *perl* there's not really any need for a native version of rebase. HOWEVER...I *can* see a case where you would want (a) your native rebase, and (b) a native "rebaseall"-ish application. And that is when your installation is so screwed up, that you can't even run dash.exe or you get the dreaded fork error when trying to run the rebaseall script. (FWIW, I'd also want to see something similar re: peflags/peflagsall to consider it a full "native" port of the rebase package). But, once that is complete, I'm sure Jason would incorporate those changes upstream -- at worst, in a mingw-specific branch, and we could ship a mingw-rebase package. Perhaps, in order to prefer at first the msys version, we'd install into /mingw/lib/rebase/ rather than /mingw/bin/, and only after a long testing period change the package to install into the "prefered" /mingw/bin location where it would take precedence over the msys one. I'll take a look at your current rebase mods later this week. > It could be > also run automatically - simply make a batch file that waits a few > seconds, kills any msys processes still running, runs rebase, re-runs > msys-sh, making it run a particular script (which is written beforehand) > that will restore the shell state (set env variables, cd into the right > directory and run the right command, probably `make $something'). I think this is overkill. Now, /perhaps/ something similar could be integrated into mingw-get (not sure if this is advisable; cygwin's setup.exe has gone for years without trying to incorporate rebasing; I suspect doing so would actually CAUSE more problems than it would solve). But I don't see a need for a fancy batch file to kill msys processes, run rebase(all).exe, restart, etc etc. > With such a tool it should be possible to rebase perl after it is > compiled and before its testsuite is run - and all that would be > completely automatic! Ah, but see, there's no need for this. All you really need to do is to rebase each newly-built XS dll (and the main msys-perl-5_N.dll) before trying to run any perl scripts (or the new perl.exe, or miniperl.exe) And doing THAT doesn't require a native perl, or to avoid bash.exe/sh.exe. You can simply add the appropriate rebase.exe command (or perlrebase invocation [*]) as part of the Makefile (or MakeMaker code). It does mean that you (probably) can't build perl with 'make -jN' (unless N=1)... In fact, that's pretty much was cygwin's perl 5.10.x distribution does, if you look in its source tarball IIRC. Also, in perl git master, there's this (as mentioned by Reini Urban earlier this morning; post hasn't shown up on the list yet): Reini wrote: > BTW, I added recently a rebaseall/perlrebase trick to perl core for > cygwin only. I believe this should be used my msys perl also, best by > just inherting from MM_Cygwin. > http://perl5.git.perl.org/perl.git/commit/172830635ea7813c85e51e This particular change really only helps when you are building cygwin (msys) perl on a system that already has cygwin (msys) perl *of the same revision* installed. It ensures that the new Cwd.dll you just built (for perl-5.A.B) uses the same image_base as the Cwd.dll already installed in /usr/lib/perl5/5.A.B/ (Obv. ditto for all other XS dlls) If your currently installed cygwin (msys) perl-5.A.B works, then this is probably a "good" address to use for the new dll... [*] I think perlrebase is written to operate on /usr/lib/perl5/$VER/, not $builddir/blib/*, but we can check with Reini if we need improvements along those lines. -- Chuck |
From: LRN <lr...@gm...> - 2011-03-03 12:29:20
|
On 02.03.2011 19:36, Charles Wilson wrote: > On 3/1/2011 10:51 AM, LRN wrote: >> On 27.02.2011 22:02, Charles Wilson wrote: >>> In any case, we might also need to bring in Reini's 'perlrebase' tool, >>> which is a script like rebaseall, but invokes rebase.exe only on perl >>> DLLs with some special settings for perl. >>> >> About rebase. I've studied its source package and have found that rebase >> can be built natively, i.e. made link against msvcrt rather than msys-1.0 >> This native rebase coupled with a program (also native) that does the >> same thing rebaseall script does (composes a list of files by >> recursively looking through directories for files ending with some >> prefixes and then invokes rebase), allows rebasing to be done outside of >> bash/dash or whatever and would make rebasing more complete. > This is all true, and would be useful -- but it's /kinda/ beside the > point re: perl. See, all of the above helps if you want to do a FULL > (Msys) system rebase: rebasing all DLLs in the entire MSYS (and MinGW?) > tree. That's exactly what i did. I've spliced perl buildscript into two parts: before msys_check() and after it. After configuring and building i've killed all remaining msys processes and ran something like this: binrebaseall.exe -v -m C:\Path\To\Msys\Root -r C:\Path\To\rebase.exe -d f:\src\perl-5.8.8-trunkfix\perl-5.8.8 -V And got the whole msys /bin and /lib subdirs as well as the whole perl source tree scanned for .dlls and each one of them rebased. I do have to admit that since rebase.exe and binrebase.exe are native, i've taken a liberty to NOT to exclude msys-1.0.dll and its friends from the list of files to be rebased, and, as a result, i've mangled everything. This doesn't seem to be appropriate in a large scale of things (re-rebasing everything every time you install some new .dlls is hardly a solution; it might be better to keep some kind of registry, with base addresses assigned to every dll, probably from the package meta-data, that way all dlls will keep their base addresses over time, and the new dlls that came without meta-data will be assigned a base address automatically, and will keep it over time as well), and i did not have time to verify that such actions had any positive effects (i DO know that after i've rebased everything once i've had to keep doing that every time i rebuilt perl, because otherwise its extensions started to conflict with msys, since it was shifted from its default safe base address - probably not a good idea, but i guess i was willing to try just about anything to make it work). > Note that we do not rebase the msys DLL during 'rebaseall' -- it is > specifically excluded. The msys DLL is compiled with a specific image > base address that is outside the range of addresses used by rebaseall > when rebasing the OTHER dlls on the system, so in this way we can hope > that the msys dll won't have a clashing image base addr anyway. Well, base address used by rebaseall is the default. The user is free to override it. But the point is moot. > *perlrebase*, on the other hand, is a shell script that ONLY rebases the > dlls associated with perl, including extension XS dlls. It also uses an > address range different than that used by rebaseall for the /rest/ of > the DLLs on the system -- this way, the two sets of DLLs will be > unlikely to have image base addresses that clash. > However, since perlrebase is a shell script, and doesn't use any perl > commands, one can hope that perl is not loaded into memory, and hence: > the DLLs associated with perl will all be rebase-able (e.g. not in use). > > So...for *perl* there's not really any need for a native version of rebase. > > HOWEVER...I *can* see a case where you would want (a) your native > rebase, and (b) a native "rebaseall"-ish application. And that is when > your installation is so screwed up, that you can't even run dash.exe or > you get the dreaded fork error when trying to run the rebaseall script. > (FWIW, I'd also want to see something similar re: peflags/peflagsall to > consider it a full "native" port of the rebase package). > > But, once that is complete, I'm sure Jason would incorporate those > changes upstream -- at worst, in a mingw-specific branch, and we could > ship a mingw-rebase package. Perhaps, in order to prefer at first the > msys version, we'd install into /mingw/lib/rebase/ rather than > /mingw/bin/, and only after a long testing period change the package to > install into the "prefered" /mingw/bin location where it would take > precedence over the msys one. Preventing binrebaseall from automatically rebasing /bin and /lib is easy enough. Base address can be specified by the user as well, so binrebaseall CAN do the same thing perlrebase does. That is, if the perl in question is isolated. Obviously, binrebaseall is not elaborate enough to filter anything out (but then it IS able to pass user-specified list of files unmodified to rebase, but then if you are able to compose such a list, then you don't really need binrebaseall). So yeah, binrebaseall focuses mostly on rebasing msys itself from outside, without resorting to dash and excluding some modules because rebaseall depends on them. >> It could be >> also run automatically - simply make a batch file that waits a few >> seconds, kills any msys processes still running, runs rebase, re-runs >> msys-sh, making it run a particular script (which is written beforehand) >> that will restore the shell state (set env variables, cd into the right >> directory and run the right command, probably `make $something'). > I think this is overkill. Now, /perhaps/ something similar could be > integrated into mingw-get (not sure if this is advisable; cygwin's > setup.exe has gone for years without trying to incorporate rebasing; I > suspect doing so would actually CAUSE more problems than it would > solve). As i have said, providing a base address for every msys package might be a good thing. It might be optional - that is, unique base address is provided, but dlls are not rebased by default - a special tool has to be used to do the rebasing. Or maybe the will be linked with these base addresses (you do that for msys, you can do that for everything else), and the tool will be there only to ensure that they won't stray from these addresses. Msys package set is and will always be limited, so it shouldn't be a problem to arrange base address assignment for all libraries in there. |
From: Reini U. <ru...@x-...> - 2011-02-27 12:17:12
|
2011/2/27 Charles Wilson <cwi...@us...>: > On 2/26/2011 8:03 PM, LRN wrote: >> On 27.02.2011 1:09, LRN wrote: >>> The change that triggers this bug was introduced between perl 5.7.2 >>> and 5.7.3 (5.7.2 builds, 5.7.3 does not). >> git bisect told me this: >> ------------------- >> 619685113277299f7d5ceee4658212496ca713ad is the first bad commit >> commit 619685113277299f7d5ceee4658212496ca713ad >> Author: Gisle Aas <gis...@pu...> >> Date: Tue Dec 11 12:52:57 2001 -0800 >> >> Passing in env to perl_parse did not work >> Message-ID: >> <lrh...@pu...> > > Here's the discussion and rationale: > http://www.nntp.perl.org/group/perl.perl5.porters/2001/12/msg48851.html > > As you can see, NOT calling mg_set() is bad juju, because it is only by > calling mg_set() that perl's idea of the environment is updated to > contain anything inherited from the "real" _environ variable OR even > from the *envp passed in via execle(). > >> Attached are the changes this commit introduces. >> >> Removing "#define USE_ENVIRON_ARRAY" from unixish.h or commenting out >> the "if (env != environ) mg_set(sv);" part in perl.c appears to solve >> the problem. However i do not understand how this code is able to >> trigger the bug. > > Well, here's my guess: > > 1) passing an env array to a child process is pretty common > 2) mucking about WITH that array, prior to fork(), can cause a change in > the memory layout of that array or the elements that it points to. > 3) This maybe could cause a mismatch in the parent/child memory layout. > 4) bang, sync_with_child error. > > In addition, there is ANOTHER issue related to *env, on win32 and > cygwin. On win32, _environ is special: > > http://msdn.microsoft.com/en-us/library/stxk41x1.aspx > > However, cygwin/msys actually maintains MULTIPLE COPIES of the > environment (especially in multithreaded situations, AND IN multiple > DLLs). There's this internal cygwin function: > update_envptrs (); /* Update any local copies of 'environ'. */ > which is called by the core worker function that setenv/putenv/setenv_r > and friends all use. It's part of dll_init.cc, and here's the body: > > /* Called from various places to update all of the individual > ideas of the environ block. Explain to me again why we didn't > just import __cygwin_environ? */ > void __stdcall > update_envptrs () > { > for (dll *d = dlls.istart (DLL_ANY); d; d = dlls.inext ()) > *(d->p.envptr) = __cygwin_environ; > *main_environ = __cygwin_environ; > } > > It updates a structure for EACH DLL loaded in the current process, to > point to the (possibly reallocated, and thus moved) __cygwin_environment. > > > So there are two things that can go wrong if you manipulate the env > pointer or its contents directly: > a) you try to write a string into a slot that is longer than the > amount of memory allocated for that slot. Eg. buffer overrun, and > something gets clobbered. > b) you update one copy of the environ by modifying it directly, > but...the other internal copies don't get updated. E.g. different > threads access different (freed?) pointers, or even in the SAME thread, > code from ONE DLL thinks the environment is --> over there, but code > from a different DLL thinks it is <-- over here. Bad bad juju. > > Answer: don't muck with environ. Instead, use setenv/putenv if you want > to make changes to the environment. > > I have a hunch that setting environ (e.g. > > environ = my_new_array; > > doesn't really work like one would hope on cygwin. This is why we use > -DPERL_USE_SAFE_PUTENV when building perl -- so that it uses > setenv/unsetenv (oddly, not putenv) when PERL wants to modify the > environment rather than "manipulating environ directly". > > But then, there's this code you've located in perl.c which does JUST > THAT: as patched, it DOES manipulate environ directly. I *think* this > might be okay, as it is in the main entry function for the interpreter > (e.g. a main()-ish function that takes argc, argv, envp) so we probably > have only one thread at that point. We DO, however, have multiple DLLs > loaded, tho. :-( > > However, if you undefine USE_ENVIRON_ARRAY, then you can't do ANY > putenv/setenv/unsetenv from perl! (This, I think, is a thinko if you > look closely at util.c, but fixing it would be somewhat awkward). > > So...one workaround here is to sorta re-integrate SOME of the stuff this > commit removed, and #define NEED_ENVIRON_DUP_FOR_MODIFY > for CYGWIN/MSYS. > > However, there's already a bug: > for (; *env; env++) { > ... > if (env != environ) > mg_set(sv); > ... > } > > Only the FIRST time thru the loop could env possibly be == environ. > > > > So, why don't you try this: replace ALL this code with what is in git > HEAD. It actually seems to make more sense to me, and avoids mucking > around too much with the environ variable directly. > > patch attached... > > Last Q, I don't know if this bit (which is still in the code) works like > we think: > > if (env_is_not_environ > ... > ) > { > environ[0] = NULL; > } > > Because it will only affect the copy of environ in THIS DLL (that is, > msys-perl5_8.dll) and not in any other DLLs. However, because external > DLLs probably don't CARE what perl did to environ, and perl XS extension > DLLs don't access environ directly anyway (they use the perl functions > to get msys-perl5_8.dll's version of the environment) I guess that > should be okay. > > Anyway, give the attached patch a shot... Your rationale sounds okay to me. But I wonder why cygwin perl does not fall over this problem also. I suggest looking into peflags -d0 also on Win7. With address space layout randomization (ASLR) on in forked perls you'll certainly get this error on Win7 during the build. But I need the exact locaction in the build chain when it happened. -- Reini Urban http://phpwiki.org/ http://murbreak.at/ |
From: Charles W. <cwi...@us...> - 2011-02-27 13:43:35
|
On 2/27/2011 7:17 AM, Reini Urban wrote: > 2011/2/27 Charles Wilson <...>: Don't feed the spammers. >> Anyway, give the attached patch a shot... > > Your rationale sounds okay to me. But I wonder why cygwin perl does > not fall over this problem also. There have been LOTS of changes in cygwin over the past seven years, especially in the area of spawn/exec/fork. I recall back in 2003-2004 were had some especially obnoxious teething pains even on cygwin, related to perl-5.8.x. Now it's MSYS's turn. Unfortunately, I don't know which changes in cygwin, from that period, are relevant for porting to MSYS to "solve" the same problem, so I think MSYS would do better to approach the problem "tabula rasa". Which is why I'm looking inside perl itself, rather than inside MSYS... > I suggest looking into peflags -d0 also on Win7. > With address space layout randomization (ASLR) on in forked perls > you'll certainly get this error on Win7 during the build. > But I need the exact locaction in the build chain when it happened. I usually saw it the first time the build process tried to execute miniperl. I'm on Vista...which supports ASLR but I dunno if it causes a problem here. I thought we (on cygwin) had pretty much come to the conclusion that chasing after ASLR and peflags -d0 was a red herring? Well, I guess it's not too hard to patch the Makefile to run peflags on miniperl... -- Chuck |
From: Reini U. <ru...@x-...> - 2011-03-02 14:01:01
|
2011/2/27 Charles Wilson: > On 2/27/2011 7:17 AM, Reini Urban wrote: >> 2011/2/27 Charles Wilson <...>: > There have been LOTS of changes in cygwin over the past seven years, > especially in the area of spawn/exec/fork. I recall back in 2003-2004 > were had some especially obnoxious teething pains even on cygwin, > related to perl-5.8.x. > > Now it's MSYS's turn. Unfortunately, I don't know which changes in > cygwin, from that period, are relevant for porting to MSYS to "solve" > the same problem, so I think MSYS would do better to approach the > problem "tabula rasa". Which is why I'm looking inside perl itself, > rather than inside MSYS... > >> I suggest looking into peflags -d0 also on Win7. >> With address space layout randomization (ASLR) on in forked perls >> you'll certainly get this error on Win7 during the build. >> But I need the exact locaction in the build chain when it happened. > > I usually saw it the first time the build process tried to execute > miniperl. I'm on Vista...which supports ASLR but I dunno if it causes a > problem here. > > I thought we (on cygwin) had pretty much come to the conclusion that > chasing after ASLR and peflags -d0 was a red herring? Well, I guess > it's not too hard to patch the Makefile to run peflags on miniperl... Not really. I tested recently perls on Windows 7 with peflags -d1 and came to the conclusion that in perl forking a perl which load dll's (XS) we get random problems. Of course because Windows randomizes the imagebase at run-time but cygwin's fork requires them to be at a fixed address. I had a wrong perlrebase for some time in the wild. BTW, I added recently a rebaseall/perlrebase trick to perl core for cygwin only. I believe this should be used my msys perl also, best by just inherting from MM_Cygwin. http://perl5.git.perl.org/perl.git/commit/172830635ea7813c85e51e -- Reini Urban http://phpwiki.org/ http://murbreak.at/ |