Failure with fork()

Failure with fork()

[Arjen Markus]

Hello,

the bug I am reporting here on behalf of Alan Irwin surfaced in the
combination wine and Cygwin (Alan summarised it here:
http://www.winehq.org/pipermail/wine-devel/2013-June/100328.html). It
has to do with the way Cygwin handles forks.

The bug can be illustrated with this small program:

int main(void) {
    while(!fork());
    return 0;
}

It is meant to enable infinite forking, but on Cygwin it immediately
stops. I tried
it on both Cygwin (not via wine but simply Windows 7) and Linux:
- On Linux the program continues without any problem
- On Cygwin it stops immediately with an error message that the child process
  terminated unexpectedly with some weird return code.

Can anyone shed light on this? This bug is a showstopper for the
combination wine
and Cygwin.

Regards,

Arjen

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

Re: Failure with fork()

[Ryan Johnson]

On 27/06/2013 5:35 AM, Arjen Markus wrote:
> Hello,
>
> the bug I am reporting here on behalf of Alan Irwin surfaced in the
> combination wine and Cygwin (Alan summarised it here:
> http://www.winehq.org/pipermail/wine-devel/2013-June/100328.html). It
> has to do with the way Cygwin handles forks.
>
> The bug can be illustrated with this small program:
>
> int main(void) {
>      while(!fork());
>      return 0;
> }
>
> It is meant to enable infinite forking, but on Cygwin it immediately
> stops. I tried
> it on both Cygwin (not via wine but simply Windows 7) and Linux:
> - On Linux the program continues without any problem
> - On Cygwin it stops immediately with an error message that the child process
>    terminated unexpectedly with some weird return code.
>
> Can anyone shed light on this? This bug is a showstopper for the
> combination wine and Cygwin.
Out of curiosity, why do you need a fork bomb? Does the script just 
capture the effect of multiple fork calls in quick succession? How many 
forks can you pull off before it croaks, and is that number consistent 
from run to run? I'd be shocked if it really died "immediately" -- as in 
"zero forked children" -- so it would be interesting to see if the issue 
is related to the number of fork calls (resource exhaustion of some 
kind), or just to how quickly they run back to back (data race of some 
kind).

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

Re: Failure with fork()

[Corinna Vinschen]

On Jun 27 07:20, Ryan Johnson wrote:
> On 27/06/2013 5:35 AM, Arjen Markus wrote:
> >Hello,
> >
> >the bug I am reporting here on behalf of Alan Irwin surfaced in the
> >combination wine and Cygwin (Alan summarised it here:
> >http://www.winehq.org/pipermail/wine-devel/2013-June/100328.html). It
> >has to do with the way Cygwin handles forks.
> >
> >The bug can be illustrated with this small program:
> >
> >int main(void) {
> >     while(!fork());
> >     return 0;
> >}
> >
> >It is meant to enable infinite forking, but on Cygwin it immediately
> >stops. I tried
> >it on both Cygwin (not via wine but simply Windows 7) and Linux:
> >- On Linux the program continues without any problem
> >- On Cygwin it stops immediately with an error message that the child process
> >   terminated unexpectedly with some weird return code.
> >
> >Can anyone shed light on this? This bug is a showstopper for the
> >combination wine and Cygwin.
> Out of curiosity, why do you need a fork bomb? Does the script just
> capture the effect of multiple fork calls in quick succession? How
> many forks can you pull off before it croaks, and is that number
> consistent from run to run? I'd be shocked if it really died
> "immediately" -- as in "zero forked children" -- so it would be
> interesting to see if the issue is related to the number of fork
> calls (resource exhaustion of some kind), or just to how quickly
> they run back to back (data race of some kind).

It dies after somewhat below 500 forks and I think I found the reason.
Stay tuned.


Corinna

-- 
Corinna Vinschen                  Please, send mails regarding Cygwin to
Cygwin Maintainer                 cygwin AT cygwin DOT com
Red Hat

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

Re: Failure with fork()

[Arjen Markus]

According to the original thread it has to do with handling the stack.
The small program is
meant to show that there is a discrepancy between the way Cygwin
handles this versus
the way Linux does that - something to do with accessing more memory
pages than expected,
but this is not an area I am familiar with ;).

> It dies after somewhat below 500 forks and I think I found the reason.
> Stay tuned.
>

I will. It would be great if this can be solved.

Regards,

Arjen

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

Re: Failure with fork()

[Corinna Vinschen]

On Jun 27 13:34, Arjen Markus wrote:
> According to the original thread it has to do with handling the stack.
> The small program is
> meant to show that there is a discrepancy between the way Cygwin
> handles this versus
> the way Linux does that - something to do with accessing more memory
> pages than expected,
> but this is not an area I am familiar with ;).
> 
> > It dies after somewhat below 500 forks and I think I found the reason.
> > Stay tuned.
> >
> 
> I will. It would be great if this can be solved.

Should be fixed in CVS.  Thanks for the report.


Corinna

-- 
Corinna Vinschen                  Please, send mails regarding Cygwin to
Cygwin Maintainer                 cygwin AT cygwin DOT com
Red Hat

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

Re: Failure with fork()

[Christopher Faylor]

On Thu, Jun 27, 2013 at 01:34:04PM +0200, Arjen Markus wrote:
>According to the original thread it has to do with handling the stack.

The original thread even pointed to the problem.  I introduced a change
back on 2013-06-18 which was supposed to fix this but Corinna found one
more place where there was a problem.

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

Re: Failure with fork()

[Alan W. Irwin]

I will attempt to answer the further posts that have come in since
my last post.

My background is I help to develop, build, and test a number of free
cross-platform software projects (e.g., PLplot).  Those projects are
mostly developed on Linux, but I want to make sure they work well on
various Windows platforms such as "bare" Windows with Windows
proprietary compilers, MinGW with MSYS, and Cygwin.  I leave checking
of Windows proprietary compiler results and any Microsoft version of
Windows to others (I don't have the money or desire to get involved
with such tests), but I would like to help out with testing the
MinGW/MSYS case and also the Cygwin case using Wine.  As a result I am
a fairly heavy but non-sophisticated user of Wine, and I have had good
success with building and testing a variety of software projects for
the combination of MinGW, MSYS, and Wine.  I have recently tried to
extend that success to the Cygwin on Wine platform, but so far no
luck.

One poster here suggested I would probably encounter a whole series of
Cygwin on Wine showstopper bugs (like unpeeling an onion).  That
negative view should be answered. Historically there has been a lot of
interest in running Cygwin on Wine by Wine developers.  According to
their bugzilla they encountered a few fairly minor problems in the
past such as the inability to resize the setup.exe GUI.  (I actually
haven't bothered to test whether that bug still exists since I didn't
care about that, but it is likely some of those bugs have disappeared
because Wine-1.6 is generally a huge advance on previous versions of
Wine.

So the only Cygwin on Wine showstopper on the list of Wine bugs I am
aware of was wine bug 24018
<http://bugs.winehq.org/show_bug.cgi?id=24018> which is actually a
Cygwin regression introduced a couple of years ago, but now fixed by
the recent efforts here.  However, because that regression persisted
so long (because of a failure to communicate the problem to the Cygwin
developers who very quickly fixed it once they became aware of it),
the Cygwin on Wine combination has essentially been untested for the
last three years.  As a result there has been a chance for additional
regressions to creep in.  But I doubt very much that there is a huge
list of such regressions that are actual showstoppers, and it is more
likely there is only one showstopper (the hang I am encountering now)
or else no showstoppers (because I am doing something wrong due to my
lack of knowledge of Cygwin).

To figure out which is the case, it is definitely time for a wine
expert with some interest in Cygwin (or Cygwin expert with some
interest in Wine) to take over now.  I have already informed the
wine-devel list of this thread, and will follow up with an additional
post there summarizing the current situation to maximize the chances
that some volunteer with the necessary expertise will step forward.

Once someone else has demonstrated setup.exe works on Wine-1.6 at
least as well as it did in the past for older Cygwin and Wine
versions, and assuming I can mimic that setup.exe success, then I have
every expectation of success with the builds and tests of free
software on the Cygwin/Wine platform. The reason for such confidence
is such build efforts would use a tool chain that is similar to the
MinGW/MSYS one that has already proved to work so well on Wine-1.6,
and because such build efforts would only involve a small subset of
Cygwin beyond that toolchain which should reduce the likelihood of
running into Cygwin or Wine bugs during such software builds.

One of the goals of that effort would be to help the PLplot project's 
Arjen Markus (the OP) who is currently our only tester of PLplot on
Cygwin (on a Microsoft Windows platform in his case) to make sure
PLplot builds and tests on Cygwin without issues regardless of
whether the underlying Windows platform is Microsoft or Wine.

Alan
__________________________
Alan W. Irwin

Astronomical research affiliation with Department of Physics and Astronomy,
University of Victoria (astrowww.phys.uvic.ca).

Programming affiliations with the FreeEOS equation-of-state
implementation for stellar interiors (freeeos.sf.net); the Time
Ephemerides project (timeephem.sf.net); PLplot scientific plotting
software package (plplot.sf.net); the libLASi project
(unifont.org/lasi); the Loads of Linux Links project (loll.sf.net);
and the Linux Brochure Project (lbproject.sf.net).
__________________________

Linux-powered Science
__________________________

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

Re: Failure with fork()

[Corinna Vinschen]

On Jun 28 02:49, gmt@malth.us wrote:
> on Fri, 28 Jun 2013, at 01:41, Corinna Vinschen thusly quipped:
> > I think it's a misconception that this very bug is the culprit of
> > Cygwin not running under wine.  Here's why:
> > 
> > What this bug did was very simple.  On each fork, the child process
> > committed 4K more stack than its parent.  The default stacksize for the
> > main thread of a process is 2 Megs.  It's a long way for a process to
> > take that much space on the stack.  So this problem should be visible
> > only in rare circumstances wher the main thread of a parent process
> > is already filled and then the child crashes because the 2 Megs are
> > overrun.  As I mentioned in my first post to this thread, the testcase
> > took almost 500 forks until the problem occured, 485 to be exact.
> > 485*4K = 1.9 Megs.
> > 
> > If anything keeps Cygwin from running under Wine, it's probably some
> > different problem, which still need investigating.
> 
> At a glance, http://bugs.winehq.org/show_bug.cgi?id=24018#c9 describes
> a seemingly plausible etiology involving the dcrt0.cc code and
> differing stack-allocation semantics between wine and windows.

That bug in Cygwin is now gone, so we're back to the stack allocation
strategy in Wine.  Or, it has nothing to do anymore with this issue
and it's something completely different.


Corinna

-- 
Corinna Vinschen                  Please, send mails regarding Cygwin to
Cygwin Maintainer                 cygwin AT cygwin DOT com
Red Hat

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

RE: Failure with fork()

[gmt]

on Fri, 28 Jun 2013, at 01:41, Corinna Vinschen thusly quipped:
> I think it's a misconception that this very bug is the culprit of
> Cygwin not running under wine.  Here's why:
> 
> What this bug did was very simple.  On each fork, the child process
> committed 4K more stack than its parent.  The default stacksize for the
> main thread of a process is 2 Megs.  It's a long way for a process to
> take that much space on the stack.  So this problem should be visible
> only in rare circumstances wher the main thread of a parent process
> is already filled and then the child crashes because the 2 Megs are
> overrun.  As I mentioned in my first post to this thread, the testcase
> took almost 500 forks until the problem occured, 485 to be exact.
> 485*4K = 1.9 Megs.
> 
> If anything keeps Cygwin from running under Wine, it's probably some
> different problem, which still need investigating.

At a glance, http://bugs.winehq.org/show_bug.cgi?id=24018#c9 describes a seemingly plausible etiology involving the dcrt0.cc code and differing stack-allocation semantics between wine and windows.

-gmt


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

RE: Failure with fork()

[gmt]

on Thu, 27 Jun 2013, at 23:42, Alan W. Irwin thusly quipped:
> I am getting absolutely nowhere.

Nonsense, you've now found the "next bug" that will be stopping cygwin from working in wine until it's fixed.  I thought that was the point of the exercise? :)

> A script run by setup.exe in the latter part of the install steps
> appears to hang now with or without updating cygwin1.dll to the
> fork-fixed version.  I got this result for two versions of
> wine which I have heavily tested in other ways, wine-1.5.19, and
> a wine-git version near wine-1.6.0-rc1.
> 
> Here are the last few messages before the hang:
> 
> Installing file cygfile:///usr/share/man/man1/xzfgrep.1.gz
> AddAccessAllowedAce(, group) failed: 1337 Installing file
> cygfile:///usr/share/man/man1/xzgrep.1.gz AddAccessAllowedAce(,
> group) failed: 1337 Installing file
> cygfile:///usr/share/man/man1/xzless.1.gz AddAccessAllowedAce(,
> group) failed: 1337 Installing file
> cygfile:///usr/share/man/man1/xzmore.1.gz AddAccessAllowedAce(,
> group) failed: 1337 AddAccessAllowedAce(, group) failed: 1337
> Extracting from
> file://Z:\home\wine\newstart\cygwin\packages/http%3a%2f%2fmirrors.k
> ernel.
> org%2fsourceware%2fcygwin%2f/release/zlib/zlib0/zlib0-1.2.8-1.tar.b
> z2 Installing file cygfile:///usr/bin/cygz.dll
> AddAccessAllowedAce(, group) failed: 1337 AddAccessAllowedAce(,
> group)

Interesting but probably not the problem.

> failed: 1337 Visited: 51 nodes out of 2986 while creating
> dependency order. Dependency order of packages: base-cygwin sed
> gzip libpcre0 gettext grep libmpfr4 gawk tzcode libgmp3 libattr1
> libncurses10 texinfo _update-info-dir libreadline7 terminfo
> libstdc++6 libncursesw10 libiconv2 libintl8 bash coreutils cygwin
> libgcc1 dash rebase _autorebase alternatives findutils base-files
> libbz2_1 bzip2 libpopt0 cygutils diffutils dos2unix editrights
> zlib0 file groff ipc-utils less liblzma5 login xz man mintty run
> tar vim-minimal which running:
> Z:\home\wine\newstart\cygwin\bin\bash.exe --norc --noprofile
> "/etc/postinstall/000-cygwin-post-install.sh"
> 
> There is no obvious chance that I can see before that hang where I can
> overwrite cygwin1.dll with the corrected version.

See my previous post for a detailed, step-by-step explanation of how to run setup.exe without installing the cygwin package.  Then you won't need to race the installer---just drop your binaries in before you run setup.exe.

>  However, if I exit
> the hang, overwrite cygwin1.dll, and run the above script
> by hand it still hung (no cpu activity and no change in the
> cygwin tree that changes its total size as measured to
> the nearest byte with "du -s --bytes cygwin") for ~20 minutes
> before I gave up.

A new behavior!  This was the second best outcome you could have possibly hoped for.

> By the way, after exiting after the first hang, if I simply
> overwrite cygwin1.dll with the corrected version, then
> run setup.exe the install stage errors out immediately with
> the message "Can't open package database for writing.  File exists."

If it happens right away that's a message from setup.exe, not cygwin1.dll.  If you deleted cygwin1.dll or put the old one back, you would almost certainly get the same result.  cygwin's /etc/setup contains the database in question.

> Instead, at that time I got the exact error
> message when running the above script concerning an unhandled page
> fault that others have described at
> http://bugs.winehq.org/show_bug.cgi?id=24018 and which the
> fork-fixed cygwin1.dll is supposed to fix.  So presumably Cygwin's
> bash.exe or some application executed by the above script has
> changed in the last month to cause the different wine symptoms. Or
> I am inadvertently doing something different than I did a month
> ago.

The old behavior was caused by a bug, clearly.  That bug has been around for ages or so people are reporting.  Perhaps, that bug is now fixed, or at least changed (like a maggot into a housefly).   Either way, yes, wine folks now have a "new" problem to look at.  But this does not imply a new bug was introduced into the wine code-base, DUCY?

The Occam's Razor explanation is that, now that it no longer crashes due to the old bug, wine gets a little bit further down the "correct" code path, before crashing in some new way -- one that you are possibly the first person -- but also very probably not the last -- ever to observe, but which was nevertheless "there all along" in the wine (or cygwin) codebase, waiting to be discovered after this one got fixed.

> So unless someone can suggest a method to get around the "Can't open
> package database for writing.  File exists." message, and assuming
> that method doesn't subsequently run into the script hang (which is a
> big if), then I think it is time for someone with a lot more wine and
> cygwin expertise than me to take over here to attempt to try and
> figure out a way to run setup.exe on Wine with fork-fixed cygwin1.dll
> overwriting the buggy version.

Sorry, I assumed you were a wine hacker in my previous post.

Unless you're willing to tackle some potentially very steep learning curves, your best bet is to post your experiences to wine's bugzilla, if you haven't done so yet, and let the wine developers take it from there.

You may or may not reach the promised-land anytime soon.  If I had to, I'd guess that once one fixes this new-but-maybe-old bug, another new-but-maybe-old bug is exposed, and once one fixes that, another, and so on, for "a while yet" before cygwin works "like a champ" in wine... the good news is, both projects are open source, so anybody sufficiently determined and "-fu"-ly equipped can fix those bugs without poring over tons of disassembled binary code and trace-logs.

-gmt


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

Re: Failure with fork()

[Corinna Vinschen]

On Jun 27 16:58, Yaakov (Cygwin/X) wrote:
> http://cygwin.com/acronyms/#PPIOSPE !
> 
> On 2013-06-27 16:52, Alan W. Irwin wrote:
> >Once the relevant snapshot is released I will let you know how far I
> 
> The 20130627 snapshot is now available.

I just uploaded a matching 64 bit 1.7.21-6 version to the 64 bit
test release.


Corinna

-- 
Corinna Vinschen                  Please, send mails regarding Cygwin to
Cygwin Maintainer                 cygwin AT cygwin DOT com
Red Hat

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

Re: Failure with fork()

[Corinna Vinschen]

On Jun 28 09:55, marco atzeri wrote:
> Il 6/28/2013 8:42 AM, Alan W. Irwin ha scritto:
> >I am getting absolutely nowhere.
> >
> [cut]
> >
> >I didn't get these hangs a month ago when I tried all this
> >before with wine-1.5.19.  Instead, at that time I got the exact error
> >message when running the above script concerning an unhandled page
> >fault that others have described at
> >http://bugs.winehq.org/show_bug.cgi?id=24018 and which the fork-fixed
> >cygwin1.dll is supposed to fix.  So presumably Cygwin's
> >bash.exe or some application executed by the above script has
> >changed in the last month to cause the different wine symptoms.
> >Or I am inadvertently doing something different than I did a month
> >ago.
> >
> >So unless someone can suggest a method to get around the "Can't open
> >package database for writing.  File exists." message, and assuming
> >that method doesn't subsequently run into the script hang (which is a
> >big if), then I think it is time for someone with a lot more wine and
> >cygwin expertise than me to take over here to attempt to try and
> >figure out a way to run setup.exe on Wine with fork-fixed cygwin1.dll
> >overwriting the buggy version.
> >
> >Alan
> 
> Hi Alan,
> I assume you are not testing on wine for fun, but cygwin on wine
> seems a real problem as the bug can be in any of the two platforms.

I think it's a misconception that this very bug is the culprit of
Cygwin not running under wine.  Here's why:

What this bug did was very simple.  On each fork, the child process
committed 4K more stack than its parent.  The default stacksize for the
main thread of a process is 2 Megs.  It's a long way for a process to
take that much space on the stack.  So this problem should be visible
only in rare circumstances wher the main thread of a parent process
is already filled and then the child crashes because the 2 Megs are
overrun.  As I mentioned in my first post to this thread, the testcase
took almost 500 forks until the problem occured, 485 to be exact.
485*4K = 1.9 Megs.

If anything keeps Cygwin from running under Wine, it's probably some
different problem, which still need investigating.

> Could you clarify the original scope ?
> Eventually we can test in your behalf.
> 
> As alternative to wine, if I am not wrong, Corinna when testing
> cygwin on several platforms (32/64, XP, W7, W8 , Server...)  is
> using some VM

Yes, I'm running VMs using Qemu/KVM with each Windows version since NT4
as guests.  Of course, that doesn't mean Cygwin should not run under
Wine, but it's not exactly a pressing issue from my POV.  I appreciate
any debugging efforts, but that probably requires somebody more fluent
with Wine internals.


Corinna

-- 
Corinna Vinschen                  Please, send mails regarding Cygwin to
Cygwin Maintainer                 cygwin AT cygwin DOT com
Red Hat

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

Re: Failure with fork()

[Alan W. Irwin]

On 2013-06-27 23:42-0700 Alan W. Irwin wrote:

> I am getting absolutely nowhere.
>
> A script run by setup.exe in the latter part of the install steps
> appears to hang now with or without updating cygwin1.dll to the
> fork-fixed version.  I got this result for two versions of
> wine which I have heavily tested in other ways, wine-1.5.19, and
> a wine-git version near wine-1.6.0-rc1.
>
> Here are the last few messages before the hang:
>
> Installing file cygfile:///usr/share/man/man1/xzfgrep.1.gz
> AddAccessAllowedAce(, group) failed: 1337
> Installing file cygfile:///usr/share/man/man1/xzgrep.1.gz
> AddAccessAllowedAce(, group) failed: 1337
> Installing file cygfile:///usr/share/man/man1/xzless.1.gz
> AddAccessAllowedAce(, group) failed: 1337
> Installing file cygfile:///usr/share/man/man1/xzmore.1.gz
> AddAccessAllowedAce(, group) failed: 1337
> AddAccessAllowedAce(, group) failed: 1337
> Extracting from
> file://Z:\home\wine\newstart\cygwin\packages/http%3a%2f%2fmirrors.kernel.org%2fsourceware%2fcygwin%2f/release/zlib/zlib0/zlib0-1.2.8-1.tar.bz2
> Installing file cygfile:///usr/bin/cygz.dll
> AddAccessAllowedAce(, group) failed: 1337
> AddAccessAllowedAce(, group) failed: 1337
> Visited: 51 nodes out of 2986 while creating dependency order.
> Dependency order of packages: base-cygwin sed gzip libpcre0 gettext
> grep libmpfr4 gawk tzcode libgmp3 libattr1 libncurses10 texinfo 
> _update-info-dir
> libreadline7 terminfo libstdc++6 libncursesw10 libiconv2
> libintl8 bash coreutils cygwin libgcc1 dash rebase _autorebase
> alternatives findutils base-files libbz2_1 bzip2 libpopt0 cygutils diffutils
> dos2unix editrights zlib0 file groff ipc-utils less liblzma5 login xz man
> mintty run tar vim-minimal which
> running: Z:\home\wine\newstart\cygwin\bin\bash.exe --norc --noprofile
> "/etc/postinstall/000-cygwin-post-install.sh"
>
> There is no obvious chance that I can see before that hang where I can
> overwrite cygwin1.dll with the corrected version.  However, if I exit
> the hang, overwrite cygwin1.dll, and run the above script
> by hand it still hung (no cpu activity and no change in the
> cygwin tree that changes its total size as measured to
> the nearest byte with "du -s --bytes cygwin") for ~20 minutes
> before I gave up.
>
> By the way, after exiting after the first hang, if I simply
> overwrite cygwin1.dll with the corrected version, then
> run setup.exe the install stage errors out immediately with
> the message "Can't open package database for writing.  File exists."
> It's for that reason that I tried to run the hanging script by hand
> to see if I could get any further.
>
> I didn't get these hangs a month ago when I tried all this
> before with wine-1.5.19.  Instead, at that time I got the exact error
> message when running the above script concerning an unhandled page
> fault that others have described at
> http://bugs.winehq.org/show_bug.cgi?id=24018 and which the fork-fixed
> cygwin1.dll is supposed to fix.  So presumably Cygwin's
> bash.exe or some application executed by the above script has
> changed in the last month to cause the different wine symptoms.
> Or I am inadvertently doing something different than I did a month
> ago.
>
> So unless someone can suggest a method to get around the "Can't open
> package database for writing.  File exists." message, and assuming
> that method doesn't subsequently run into the script hang (which is a
> big if), then I think it is time for someone with a lot more wine and
> cygwin expertise than me to take over here to attempt to try and
> figure out a way to run setup.exe on Wine with fork-fixed cygwin1.dll
> overwriting the buggy version.

I did a few more experiments.  If cygwin/bin is on the PATH, the
explicit MSYS bash version runs the script with no issues.  So it is
likely the hang is caused by the Cygwin version of bash rather than
something run in the script.

I also was able to get around the "Can't open package database for
writing.  File exists." issue.  I searched for anything associated
with databases by using

find cygwin -iname "*db*"

which found

cygwin/etc/setup/installed.db.new
cygwin/etc/setup/installed.db

which were identical.  If I removed cygwin/etc/setup/installed.db,
then I could rerun setup.exe without the error message showing up. 
However, as some of the applications were installed on top of the same
applications that had been installed for the previous setup.exe run, I
got occasional messages about overwriting files in use.  I just
answered all those error boxes as "continue" and that allowed the
second try for setup.exe to get as far as the first try.  However, it
got absolutely no further because the same script hung again!
Also, all these installs on top of the old installs presumably overwrote
cygwin1.dll with the fork-buggy version again.  So it is very likely
that
cygwin/etc/setup/installed.db is probably not the right workaround.
Instead, presumably something changed by the hanging script or
some script that setup.exe would normally run afterwards sets up
setup.exe so it can be rerun without overwriting the executables.

So I am willing to try a few more experiments that one of you may
suggest, but my Cygwin expertise is minimal/nonexistent, and it is
probably time for someone else with both Cygwin and Wine expertise to
step in to investigate the hanging script I described above.

Alan
__________________________
Alan W. Irwin

Astronomical research affiliation with Department of Physics and Astronomy,
University of Victoria (astrowww.phys.uvic.ca).

Programming affiliations with the FreeEOS equation-of-state
implementation for stellar interiors (freeeos.sf.net); the Time
Ephemerides project (timeephem.sf.net); PLplot scientific plotting
software package (plplot.sf.net); the libLASi project
(unifont.org/lasi); the Loads of Linux Links project (loll.sf.net);
and the Linux Brochure Project (lbproject.sf.net).
__________________________

Linux-powered Science
__________________________

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

Re: Failure with fork()

[marco atzeri]

Il 6/28/2013 8:42 AM, Alan W. Irwin ha scritto:
> I am getting absolutely nowhere.
>
[cut]
>
> I didn't get these hangs a month ago when I tried all this
> before with wine-1.5.19.  Instead, at that time I got the exact error
> message when running the above script concerning an unhandled page
> fault that others have described at
> http://bugs.winehq.org/show_bug.cgi?id=24018 and which the fork-fixed
> cygwin1.dll is supposed to fix.  So presumably Cygwin's
> bash.exe or some application executed by the above script has
> changed in the last month to cause the different wine symptoms.
> Or I am inadvertently doing something different than I did a month
> ago.
>
> So unless someone can suggest a method to get around the "Can't open
> package database for writing.  File exists." message, and assuming
> that method doesn't subsequently run into the script hang (which is a
> big if), then I think it is time for someone with a lot more wine and
> cygwin expertise than me to take over here to attempt to try and
> figure out a way to run setup.exe on Wine with fork-fixed cygwin1.dll
> overwriting the buggy version.
>
> Alan

Hi Alan,
I assume you are not testing on wine for fun, but cygwin on wine
seems a real problem as the bug can be in any of the two platforms.

Could you clarify the original scope ?
Eventually we can test in your behalf.

As alternative to wine, if I am not wrong, Corinna when testing cygwin 
on several platforms (32/64, XP, W7, W8 , Server...)  is using some VM
and also her main compiling machine is a Linux one;
setup.exe itself is cross-compiled on a Linux machine.
Eventually it is a more easy approuch for your trials

Regards
Marco




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

Re: Failure with fork()

[Alan W. Irwin]

I am getting absolutely nowhere.

A script run by setup.exe in the latter part of the install steps
appears to hang now with or without updating cygwin1.dll to the
fork-fixed version.  I got this result for two versions of
wine which I have heavily tested in other ways, wine-1.5.19, and
a wine-git version near wine-1.6.0-rc1.

Here are the last few messages before the hang:

Installing file cygfile:///usr/share/man/man1/xzfgrep.1.gz
AddAccessAllowedAce(, group) failed: 1337
Installing file cygfile:///usr/share/man/man1/xzgrep.1.gz
AddAccessAllowedAce(, group) failed: 1337
Installing file cygfile:///usr/share/man/man1/xzless.1.gz
AddAccessAllowedAce(, group) failed: 1337
Installing file cygfile:///usr/share/man/man1/xzmore.1.gz
AddAccessAllowedAce(, group) failed: 1337
AddAccessAllowedAce(, group) failed: 1337
Extracting from
file://Z:\home\wine\newstart\cygwin\packages/http%3a%2f%2fmirrors.kernel.org%2fsourceware%2fcygwin%2f/release/zlib/zlib0/zlib0-1.2.8-1.tar.bz2
Installing file cygfile:///usr/bin/cygz.dll
AddAccessAllowedAce(, group) failed: 1337
AddAccessAllowedAce(, group) failed: 1337
Visited: 51 nodes out of 2986 while creating dependency order.
Dependency order of packages: base-cygwin sed gzip libpcre0 gettext
grep libmpfr4 gawk tzcode libgmp3 libattr1 libncurses10 texinfo _update-info-dir
libreadline7 terminfo libstdc++6 libncursesw10 libiconv2
libintl8 bash coreutils cygwin libgcc1 dash rebase _autorebase
alternatives findutils base-files libbz2_1 bzip2 libpopt0 cygutils diffutils
dos2unix editrights zlib0 file groff ipc-utils less liblzma5 login xz man
mintty run tar vim-minimal which
running: Z:\home\wine\newstart\cygwin\bin\bash.exe --norc --noprofile
"/etc/postinstall/000-cygwin-post-install.sh"

There is no obvious chance that I can see before that hang where I can
overwrite cygwin1.dll with the corrected version.  However, if I exit
the hang, overwrite cygwin1.dll, and run the above script
by hand it still hung (no cpu activity and no change in the
cygwin tree that changes its total size as measured to
the nearest byte with "du -s --bytes cygwin") for ~20 minutes
before I gave up.

By the way, after exiting after the first hang, if I simply
overwrite cygwin1.dll with the corrected version, then
run setup.exe the install stage errors out immediately with
the message "Can't open package database for writing.  File exists."
It's for that reason that I tried to run the hanging script by hand
to see if I could get any further.

I didn't get these hangs a month ago when I tried all this
before with wine-1.5.19.  Instead, at that time I got the exact error
message when running the above script concerning an unhandled page
fault that others have described at
http://bugs.winehq.org/show_bug.cgi?id=24018 and which the fork-fixed
cygwin1.dll is supposed to fix.  So presumably Cygwin's
bash.exe or some application executed by the above script has
changed in the last month to cause the different wine symptoms.
Or I am inadvertently doing something different than I did a month
ago.

So unless someone can suggest a method to get around the "Can't open
package database for writing.  File exists." message, and assuming
that method doesn't subsequently run into the script hang (which is a
big if), then I think it is time for someone with a lot more wine and
cygwin expertise than me to take over here to attempt to try and
figure out a way to run setup.exe on Wine with fork-fixed cygwin1.dll
overwriting the buggy version.

Alan
__________________________
Alan W. Irwin

Astronomical research affiliation with Department of Physics and Astronomy,
University of Victoria (astrowww.phys.uvic.ca).

Programming affiliations with the FreeEOS equation-of-state
implementation for stellar interiors (freeeos.sf.net); the Time
Ephemerides project (timeephem.sf.net); PLplot scientific plotting
software package (plplot.sf.net); the libLASi project
(unifont.org/lasi); the Loads of Linux Links project (loll.sf.net);
and the Linux Brochure Project (lbproject.sf.net).
__________________________

Linux-powered Science
__________________________

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

Re: Failure with fork()

[Larry Hall (Cygwin)]

On 6/27/2013 4:55 PM, Thrall, Bryan wrote:
> Larry Hall (Cygwin) wrote on 2013-06-27:
>> On 6/27/2013 4:33 PM, Alan W. Irwin wrote:
>>> So the question still remains how do I gain access to a version of
>>> setup.exe with the fork fix that will allow me to not only initialize
>>> my Cygwin distribution for Wine without the fork abort, but also
>>> subsequently update it to install all components of Cygwin that I
>>> need?
>>
>> Since you want to just run 'setup.exe', you need a new cygwin package
>> (i.e. cygwin-1.7.2*-*) before you'll be able to do what you want
>> without any extra effort on your part.  So unless you're willing to
>> build your own version of this package and put it in your download
>> directory in the appropriate spot (after you've downloaded the
>> packages you want), you want to just wait for the next announcement
>> for the cygwin package.
>
> Since the fork bug is only affecting the execution of the postinstall
> scripts, couldn't the OP install the snapshot in the partially-complete
> Cygwin install, then run setup.exe to finish the postinstall scripts?

As Yaakov said, if you time it just right, which may or may not be
tricky.  There are other alternatives as well but they all require
some effort to get right.

-- 
Larry

_____________________________________________________________________

A: Yes.
 > Q: Are you sure?
 >> A: Because it reverses the logical flow of conversation.
 >>> Q: Why is top posting annoying in email?

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

Re: Failure with fork()

[Yaakov (Cygwin/X)]

http://cygwin.com/acronyms/#PPIOSPE !

On 2013-06-27 16:52, Alan W. Irwin wrote:
> Once the relevant snapshot is released I will let you know how far I

The 20130627 snapshot is now available.

> get with a variant of the above I have thought of which is replacing
> cygwin1.dll on the fly when the individual step of the initial run of
> setup.exe that installs cygwin1.dll is completed.  That method takes
> advantage of the fact that the fork issue only occurs during the final
> step of the install and presumably nothing is using cygwin1.dll when
> the prior step that installs cygwin1.dll is completed.  So ideally
> this method would be completely error free, but I will see about that,
> and if not I will fall back to trying your method.

That might just work, if you get the timing right.


Yaakov


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

Re: Failure with fork()

[Alan W. Irwin]

On 2013-06-27 15:56-0500 Yaakov (Cygwin/X) wrote:

> On 2013-06-27 15:33, Alan W. Irwin wrote:
>> I think you keep assuming I have some version of Cygwin already
>> installed when that is not the case.  It is the last stage of the
>> initial attempt at installation using setup.exe that fails on Wine due
>> to the fork bug. Furthermore, when I download setup.exe from
>> http://cygwin.com/setup.exe it contains the fork bug. That version is
>> self-contained, i.e., only setup.exe needs to be downloaded, not
>> cygwin1.dll in addition.  I presume that is because setup.exe uses a
>> static version of the cygwin library as a matter of convenience rather
>> than depending on an external cygwin1.dll that could be separately
>> downloaded.
>
> There is no such thing as static linkage of Cygwin.  setup.exe is in fact a 
> native Windows (MinGW) executable, due to the fact that it needs to be able 
> to run before Cygwin is installed, or while upgrading cygwin1.dll.
>
> Therefore, if you are seeing fork() errors when running setup, they are 
> actually coming from the postinstall scripts which are run after installing 
> files.  In that case, the best solution may be something along the lines of 
> (untested):
>
> 1) Open the Wine equivalent of taskmgr.exe.
> 2) Run setup.exe again and install just the Base packages.
> 3) During postinstall, kill any bash.exe processes ASAP.
> 4) setup.exe should list some postinstall errors before completion, which can 
> be ignored for now.
> 5) After setup.exe is finished, replace C:\cygwin\bin\cygwin1.dll with the 
> latest snapshot DLL.
> 6) Run setup.exe again with the same options; the postinstall scripts should 
> (in theory) run properly this time.
> 7) Launch Cygwin Terminal once to set up your environment.
> 8) Run setup.exe one more time to install additional packages.
>

Once the relevant snapshot is released I will let you know how far I
get with a variant of the above I have thought of which is replacing
cygwin1.dll on the fly when the individual step of the initial run of
setup.exe that installs cygwin1.dll is completed.  That method takes
advantage of the fact that the fork issue only occurs during the final
step of the install and presumably nothing is using cygwin1.dll when
the prior step that installs cygwin1.dll is completed.  So ideally
this method would be completely error free, but I will see about that,
and if not I will fall back to trying your method.

Thanks to you and the many (!) other posters here for clarifying the
issue (i.e., that the fork issue I see as a result of running
setup.exe is in one of the invoked commands that are linked to
cygwin1.dll that is downloaded by setup.exe and not in setup.exe
itself.)

More later.

Alan
__________________________
Alan W. Irwin

Astronomical research affiliation with Department of Physics and Astronomy,
University of Victoria (astrowww.phys.uvic.ca).

Programming affiliations with the FreeEOS equation-of-state
implementation for stellar interiors (freeeos.sf.net); the Time
Ephemerides project (timeephem.sf.net); PLplot scientific plotting
software package (plplot.sf.net); the libLASi project
(unifont.org/lasi); the Loads of Linux Links project (loll.sf.net);
and the Linux Brochure Project (lbproject.sf.net).
__________________________

Linux-powered Science
__________________________

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

Re: Failure with fork()

[Yaakov (Cygwin/X)]

On 2013-06-27 15:33, Alan W. Irwin wrote:
> I think you keep assuming I have some version of Cygwin already
> installed when that is not the case.  It is the last stage of the
> initial attempt at installation using setup.exe that fails on Wine due
> to the fork bug. Furthermore, when I download setup.exe from
> http://cygwin.com/setup.exe it contains the fork bug. That version is
> self-contained, i.e., only setup.exe needs to be downloaded, not
> cygwin1.dll in addition.  I presume that is because setup.exe uses a
> static version of the cygwin library as a matter of convenience rather
> than depending on an external cygwin1.dll that could be separately
> downloaded.

There is no such thing as static linkage of Cygwin.  setup.exe is in 
fact a native Windows (MinGW) executable, due to the fact that it needs 
to be able to run before Cygwin is installed, or while upgrading 
cygwin1.dll.

Therefore, if you are seeing fork() errors when running setup, they are 
actually coming from the postinstall scripts which are run after 
installing files.  In that case, the best solution may be something 
along the lines of (untested):

1) Open the Wine equivalent of taskmgr.exe.
2) Run setup.exe again and install just the Base packages.
3) During postinstall, kill any bash.exe processes ASAP.
4) setup.exe should list some postinstall errors before completion, 
which can be ignored for now.
5) After setup.exe is finished, replace C:\cygwin\bin\cygwin1.dll with 
the latest snapshot DLL.
6) Run setup.exe again with the same options; the postinstall scripts 
should (in theory) run properly this time.
7) Launch Cygwin Terminal once to set up your environment.
8) Run setup.exe one more time to install additional packages.

HTH,


Yaakov


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

RE: Failure with fork()

[Thrall, Bryan]

Larry Hall (Cygwin) wrote on 2013-06-27:
> On 6/27/2013 4:33 PM, Alan W. Irwin wrote:
>> So the question still remains how do I gain access to a version of
>> setup.exe with the fork fix that will allow me to not only initialize
>> my Cygwin distribution for Wine without the fork abort, but also
>> subsequently update it to install all components of Cygwin that I
>> need?
> 
> Since you want to just run 'setup.exe', you need a new cygwin package
> (i.e. cygwin-1.7.2*-*) before you'll be able to do what you want
> without any extra effort on your part.  So unless you're willing to
> build your own version of this package and put it in your download
> directory in the appropriate spot (after you've downloaded the
> packages you want), you want to just wait for the next announcement
> for the cygwin package.

Since the fork bug is only affecting the execution of the postinstall
scripts, couldn't the OP install the snapshot in the partially-complete
Cygwin install, then run setup.exe to finish the postinstall scripts?

--
Bryan Thrall
Principal Software Engineer
FlightSafety International * Visual Simulation Systems * 5695 Campus
Parkway  * Hazelwood, MO 63042
Tel: (314) 551-8413 * Fax: (314) 551-8444
bryan.thrall@flightsafety.com * www.flightsafety.com * A Berkshire
Hathaway company



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

Re: Failure with fork()

[Peter Rosin]

On 2013-06-27 22:33, Alan W. Irwin wrote:
> I think you keep assuming I have some version of Cygwin already
> installed when that is not the case.  It is the last stage of the
> initial attempt at installation using setup.exe that fails on Wine due
> to the fork bug. Furthermore, when I download setup.exe from
> http://cygwin.com/setup.exe it contains the fork bug. That version is
> self-contained, i.e., only setup.exe needs to be downloaded, not
> cygwin1.dll in addition.  I presume that is because setup.exe uses a
> static version of the cygwin library as a matter of convenience rather
> than depending on an external cygwin1.dll that could be separately
> downloaded.

I think the real reason is that setup has downloaded and installed
cygwin1.dll, and is using it when running the post-install scripts.
There is no statically linked cygwin library in setup.exe.

> So the question still remains how do I gain access to a version of
> setup.exe with the fork fix that will allow me to not only initialize
> my Cygwin distribution for Wine without the fork abort, but also
> subsequently update it to install all components of Cygwin that I
> need?

If the procedure in [1] is too complicated, you will have to wait for
a new cygwin package to be released.

Cheers,
Peter

[1] http://cygwin.com/ml/cygwin/2013-06/msg00697.html


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

Re: Failure with fork()

[Larry Hall (Cygwin)]

On 6/27/2013 4:33 PM, Alan W. Irwin wrote:
<snip>

> I think you keep assuming I have some version of Cygwin already
> installed when that is not the case.  It is the last stage of the
> initial attempt at installation using setup.exe that fails on Wine due
> to the fork bug. Furthermore, when I download setup.exe from
> http://cygwin.com/setup.exe it contains the fork bug. That version is
> self-contained, i.e., only setup.exe needs to be downloaded, not
> cygwin1.dll in addition.  I presume that is because setup.exe uses a
> static version of the cygwin library as a matter of convenience rather
> than depending on an external cygwin1.dll that could be separately
> downloaded.

No not really.  'setup.exe' is a pure Windows executable.  It doesn't
rely on cygwin1.dll at all.  However, as part of the installation process
for individual packages, there are (possible) preremove and postinstall
scripts.  These are shell scripts that invoke Cygwin utilities.  These
utilities, therefore, use cygwin1.dll.  This is where you were seeing
the problem.

> I have looked at the table of contents of the latest
> cygwin-inst-20130619.tar.bz2 since that appears to be the most
> complete recent snapshot version.  Although it does contain a number
> of *.exe files and other core components of cygwin as advertised it is
> missing many components of Cygwin that I need.  Also, it is missing
> the key setup.exe core component which precludes any chance of
> installing the rest of what I need based on this snapshot version of
> Cygwin.

'setup.exe' is built from separate sources.  See
<http://sourceware.org/cygwin-apps/setup.html> for details.  But I don't
think this is really what you want.

> So the question still remains how do I gain access to a version of
> setup.exe with the fork fix that will allow me to not only initialize
> my Cygwin distribution for Wine without the fork abort, but also
> subsequently update it to install all components of Cygwin that I
> need?

Since you want to just run 'setup.exe', you need a new cygwin package
(i.e. cygwin-1.7.2*-*) before you'll be able to do what you want
without any extra effort on your part.  So unless you're willing to
build your own version of this package and put it in your download
directory in the appropriate spot (after you've downloaded the
packages you want), you want to just wait for the next announcement
for the cygwin package.


-- 
Larry

_____________________________________________________________________

A: Yes.
 > Q: Are you sure?
 >> A: Because it reverses the logical flow of conversation.
 >>> Q: Why is top posting annoying in email?

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

Re: Failure with fork()

[Christopher Faylor]

On Thu, Jun 27, 2013 at 01:33:53PM -0700, Alan W. Irwin wrote:
>On 2013-06-27 21:13+0200 marco atzeri wrote:
>
>> Il 6/27/2013 9:01 PM, Alan W. Irwin ha scritto:
>>> I have now found the snapshots page, and the latest one
>>> contains
>>> 
>>> 013-06-18  Christopher Faylor  <me.cygwin2013@cgf.cx>
>>> 
>>> * dcrt0.cc (child_info_fork::alloc_stack): Don't subtract 4096 from
>>> stack pointer since getstack() already does that.
>>> 
>>> Could someone confirm that is the fork fix of interest here?
>>
>> Of course not. Corinna solved the problem today
>> and cygwin1-20130619.dll.bz2 was built last 19th June
>> so you need to wait the next one.
>
>Sorry about that.  Didn't check the date, and it looked promising
>because of that reference to fork and the stack.

http://cygwin.com/ml/cygwin/2013-06/msg00684.html

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

Re: Failure with fork()

[Alan W. Irwin]

On 2013-06-27 21:13+0200 marco atzeri wrote:

> Il 6/27/2013 9:01 PM, Alan W. Irwin ha scritto:
>> I have now found the snapshots page, and the latest one
>> contains
>> 
>> 013-06-18  Christopher Faylor  <me.cygwin2013@cgf.cx>
>> 
>> * dcrt0.cc (child_info_fork::alloc_stack): Don't subtract 4096 from
>> stack pointer since getstack() already does that.
>> 
>> Could someone confirm that is the fork fix of interest here?
>
> Of course not. Corinna solved the problem today
> and cygwin1-20130619.dll.bz2 was built last 19th June
> so you need to wait the next one.

Sorry about that.  Didn't check the date, and it looked promising
because of that reference to fork and the stack.

>> 
>> I am somewhat confused by the remark
>> at http://cygwin.com/faq-nochunks.html#faq.setup.snapshots
>> that "You cannot use Cygwin Setup to install a snapshot."
>> 
>> So what exactly is installed by a snapshot?  Is it just the core part
>> of Cygwin?
>
> It is just the core cygwin1.dll
> The easy way is copy the new one on the current one.
> Of course all cygwin processes must be shutdown before..

I think you keep assuming I have some version of Cygwin already
installed when that is not the case.  It is the last stage of the
initial attempt at installation using setup.exe that fails on Wine due
to the fork bug. Furthermore, when I download setup.exe from
http://cygwin.com/setup.exe it contains the fork bug. That version is
self-contained, i.e., only setup.exe needs to be downloaded, not
cygwin1.dll in addition.  I presume that is because setup.exe uses a
static version of the cygwin library as a matter of convenience rather
than depending on an external cygwin1.dll that could be separately
downloaded.

I have looked at the table of contents of the latest
cygwin-inst-20130619.tar.bz2 since that appears to be the most
complete recent snapshot version.  Although it does contain a number
of *.exe files and other core components of cygwin as advertised it is
missing many components of Cygwin that I need.  Also, it is missing
the key setup.exe core component which precludes any chance of
installing the rest of what I need based on this snapshot version of
Cygwin.

So the question still remains how do I gain access to a version of
setup.exe with the fork fix that will allow me to not only initialize
my Cygwin distribution for Wine without the fork abort, but also
subsequently update it to install all components of Cygwin that I
need?

Alan
__________________________
Alan W. Irwin

Astronomical research affiliation with Department of Physics and Astronomy,
University of Victoria (astrowww.phys.uvic.ca).

Programming affiliations with the FreeEOS equation-of-state
implementation for stellar interiors (freeeos.sf.net); the Time
Ephemerides project (timeephem.sf.net); PLplot scientific plotting
software package (plplot.sf.net); the libLASi project
(unifont.org/lasi); the Loads of Linux Links project (loll.sf.net);
and the Linux Brochure Project (lbproject.sf.net).
__________________________

Linux-powered Science
__________________________

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

RE: Failure with fork()

[gmt]

on Thu, 27 Jun 2013, at 12:22, Alan W. Irwin thusly quipped:
> On 2013-06-27 21:00+0200 marco atzeri wrote:
> 
>> Il 6/27/2013 8:35 PM, Alan W. Irwin ha scritto:
>>> Are there daily snapshot builds of the CVS version I could access?
>> 
>> daily not, but on reasonable schedule
>> (aka when Corinna or Christopher release one)
>> 
>> http://cygwin.com/snapshots/
>> 
>> just wait for the next cygwin1-20130xxx.dll.bz2
>> and replace the installed cygwin1.dll with the new one
> 
> I haven't even gotten as far as an initial install because
> of this fork bug.
> 
> From the Linux command line here is what I did some time ago (for a
> wine-git version very close to wine-1.6.0-rc1 and for (presumably) the
> latest stable release of setup.exe downloaded from
> http://cygwin.com/setup.exe) when I first ran into the fork bug:
> 
> wineconsole setup.exe

I haven't tried this myself (yet), but if you "can't wait", and have access to a mingw64 cross-compiler, you can likely get cygwin cvs here: http://cygwin.com/cvs.html, and, from there, follow a fairly typical cross-compiling configure && make && make install DESTDIR=foo && tar type of process to create your own "ghetto" snapshot, that you could drop into place on top of your your half-completed nascent cyg-wine install.  From there, you could run setup.exe, uncheck the "cygwin" and "newlib" packages, and then, when setup.exe prompts you to put those packages back in, uncheck the box (by default, checked) specifying to add them.

Assuming you get that far, successfully, you'd then expect to see some results -- either finding the next bug, discovering the bug still exists, somehow, or that everything is magically fixed... what-have-you.

Alternatively, you could try to create a cross-cygport.  Not sure how easy/hard that is, but I'd guess it's fairly straightforward.  Cygport by default generates "setup.exe"-compatible package-trees that, if I'm not mistaken, by following easily-google-able advice, can be overlaid into your setup.exe's package-set so that you could follow a standard setup.exe process without having to uncheck those core packages.

No idea what results you'll get -- very likely an anticlimax where you simply find the next bug -- but one of the above would probably allow you to proceed; worst-case you'd at least have a build environment, for future testing/hacking, that you could recycle. 

-gmt


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

Re: Failure with fork()

[Achim Gratz]

Alan W. Irwin writes:
> I haven't even gotten as far as an initial install because
> of this fork bug.

If you've never installed Cygwin then this is going to be a bit
more difficult, but here it is anyway...

You'll need a cygwin package that has the snapshot files built in.  To
do this, unpack the files from the current cygwin package into a
temporary directory, then unpack the snapshot files into the same
directory (which updates the directory with the filesfrom the snapshot),
package the directory up again as a tar.bz2 file, note the md5sum and
change the entry in setup.ini for the package to have the correct
filename (if you've changed it) and checksum.  You should then be able
to use setup.exe just fine to install a new Cygwin instance.


Here's a Makefile that will do the packaging, adjust the locations:

--8<---------------cut here---------------start------------->8---
.PHONY: all install clean force-clean clean-install snapshot install-snapshot snapshot-debuginfo install-snapshot-debuginfo

CV ?= 1.7.19
CR ?= 1
CVR = $(CV)-$(CR)
SD ?= 20130627

CYGMIR   = /mnt/mirror/cygwin/release/cygwin
CYGDEB   = $(CYGMIR)/cygwin-debuginfo
SNAPSHOT = $(PWD)/snapshot-$(SD)
SNAPDEB  = $(PWD)/snapshot-debuginfo-$(SD)
SNAPMIR  = /mnt/mirror/snapshot
PATCH    = /mnt/mirror/patch/release/cygwin
PATCHDEB = $(PATCH)/cygwin-debuginfo

all:            snapshot snapshot-debuginfo
install:        clean-install clean install-snapshot install-snapshot-debuginfo force-clean
clean force-clean:
        rm -fr     $(SNAPSHOT)
        rm -fr     $(SNAPDEB)
clean-install:  clean
        rm -f      $(PATCH)/cygwin-$(CVR)s$(SD).tar.bz2 $(PATCHDEB)/cygwin-debuginfo-$(CVR)s$(SD).tar.bz2

snapshot:
        mkdir   -p $(SNAPSHOT)
        tar     -C $(SNAPSHOT) -xf $(CYGMIR)/cygwin-$(CVR).tar.bz2
        tar     -C $(SNAPSHOT) -xf /mnt/mirror/snapshot/cygwin-inst-$(SD).tar.bz2
install-snapshot:       snapshot
        tar     -C $(SNAPSHOT) -cf $(PATCH)/cygwin-$(CVR)s$(SD).tar.bz2 etc/ usr/

snapshot-debuginfo:
        mkdir   -p $(SNAPDEB)
        tar     -C $(SNAPDEB)  -xf $(CYGDEB)/cygwin-debuginfo-$(CVR).tar.bz2
        bunzip2 -c $(SNAPMIR)/cygwin1-$(SD).dbg.bz2 > $(SNAPDEB)/usr/lib/debug/usr/bin/cygwin1.dbg
        touch   -r $(SNAPMIR)/cygwin1-$(SD).dbg.bz2 $(SNAPDEB)/usr/lib/debug/usr/bin/cygwin1.dbg
install-snapshot-debuginfo:     snapshot-debuginfo
        tar     -C $(SNAPDEB) -cf $(PATCHDEB)/cygwin-debuginfo-$(CVR)s$(SD).tar.bz2 usr/
--8<---------------cut here---------------end--------------->8---


Regards,
Achim.
-- 
+<[Q+ Matrix-12 WAVE#46+305 Neuron microQkb Andromeda XTk Blofeld]>+

Samples for the Waldorf Blofeld:
http://Synth.Stromeko.net/Downloads.html#BlofeldSamplesExtra


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

Re: Failure with fork()

[Alan W. Irwin]

On 2013-06-27 21:00+0200 marco atzeri wrote:

> Il 6/27/2013 8:35 PM, Alan W. Irwin ha scritto:
>> Are there daily snapshot builds of the CVS version I could access?
>
> daily not, but on reasonable schedule
> (aka when Corinna or Christopher release one)
>
> http://cygwin.com/snapshots/
>
> just wait for the next cygwin1-20130xxx.dll.bz2
> and replace the installed cygwin1.dll with the new one

I haven't even gotten as far as an initial install because
of this fork bug.

From the Linux command line here is what I did some time ago (for a
wine-git version very close to wine-1.6.0-rc1 and for (presumably) the
latest stable release of setup.exe downloaded from
http://cygwin.com/setup.exe) when I first ran into the fork bug:

wineconsole setup.exe

The setup GUI fired up, I went through all the screens without issues, but
then the final screen completely bombed out due to this fork bug.  Any
attempts to use setup.exe afterward failed immediately (presumably
because that aborted last screen of the GUI did not complete some
critical task.)

So I think I have to do a complete installation from
cygwin-inst-YYYYMMDD.tar.bz2, and assuming that contains setup.exe,
run that version from wineconsole to obtain a a Cygwin system where I
select the further packages I need to have installed (the build tools
as well as some important library dependencies such as pango, cairo,
and Qt4) so that I can build further software on the Cygwin platform.
Do you agree this is the right approach?

Also, I think the current snapshot actually does contain
the fork bug fix, but I have asked for confirmation of
that in my last post.

Alan
__________________________
Alan W. Irwin

Astronomical research affiliation with Department of Physics and Astronomy,
University of Victoria (astrowww.phys.uvic.ca).

Programming affiliations with the FreeEOS equation-of-state
implementation for stellar interiors (freeeos.sf.net); the Time
Ephemerides project (timeephem.sf.net); PLplot scientific plotting
software package (plplot.sf.net); the libLASi project
(unifont.org/lasi); the Loads of Linux Links project (loll.sf.net);
and the Linux Brochure Project (lbproject.sf.net).
__________________________

Linux-powered Science
__________________________

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

Re: Failure with fork()

[marco atzeri]

Il 6/27/2013 9:01 PM, Alan W. Irwin ha scritto:
> On 2013-06-27 11:35-0700 Alan W. Irwin wrote:
>
>> The only Windows platform available to me is Wine.  And I have
>> no Cygwin on Wine experience at this stage because this fork bug shut
>> me out.  But now that it is fixed in CVS, how do I get access to
>> the fixed version of setup.exe?
>>
>> Are there daily snapshot builds of the CVS version I could access?
>
> Never mind.  I have now found the snapshots page, and the latest one
> contains
>
> 013-06-18  Christopher Faylor  <me.cygwin2013@cgf.cx>
>
> * dcrt0.cc (child_info_fork::alloc_stack): Don't subtract 4096 from
> stack pointer since getstack() already does that.
>
> Could someone confirm that is the fork fix of interest here?

Of course not. Corinna solved the problem today
and cygwin1-20130619.dll.bz2 was built last 19th June
so you need to wait the next one.

>
> I am somewhat confused by the remark
> at http://cygwin.com/faq-nochunks.html#faq.setup.snapshots
> that "You cannot use Cygwin Setup to install a snapshot."
>
> So what exactly is installed by a snapshot?  Is it just the core part
> of Cygwin?

It is just the core cygwin1.dll
The easy way is copy the new one on the current one.
Of course all cygwin processes must be shutdown before..

> Is there enough included in cygwin-inst-YYYYMMDD.tar.bz2
> so I can run setup.exe from the installed version of that tarball to
> download and install or update additional Cygwin components that I
> might need?
>
> Alan
> __________________________
> Alan W. Irwin
>
>

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

Re: Failure with fork()

[Alan W. Irwin]

On 2013-06-27 11:35-0700 Alan W. Irwin wrote:

> The only Windows platform available to me is Wine.  And I have
> no Cygwin on Wine experience at this stage because this fork bug shut
> me out.  But now that it is fixed in CVS, how do I get access to
> the fixed version of setup.exe?
>
> Are there daily snapshot builds of the CVS version I could access?

Never mind.  I have now found the snapshots page, and the latest one
contains

013-06-18  Christopher Faylor  <me.cygwin2013@cgf.cx>

* dcrt0.cc (child_info_fork::alloc_stack): Don't subtract 4096 from
stack pointer since getstack() already does that.

Could someone confirm that is the fork fix of interest here?

I am somewhat confused by the remark
at http://cygwin.com/faq-nochunks.html#faq.setup.snapshots
that "You cannot use Cygwin Setup to install a snapshot."

So what exactly is installed by a snapshot?  Is it just the core part
of Cygwin?  Is there enough included in cygwin-inst-YYYYMMDD.tar.bz2
so I can run setup.exe from the installed version of that tarball to
download and install or update additional Cygwin components that I
might need?

Alan
__________________________
Alan W. Irwin

Astronomical research affiliation with Department of Physics and Astronomy,
University of Victoria (astrowww.phys.uvic.ca).

Programming affiliations with the FreeEOS equation-of-state
implementation for stellar interiors (freeeos.sf.net); the Time
Ephemerides project (timeephem.sf.net); PLplot scientific plotting
software package (plplot.sf.net); the libLASi project
(unifont.org/lasi); the Loads of Linux Links project (loll.sf.net);
and the Linux Brochure Project (lbproject.sf.net).
__________________________

Linux-powered Science
__________________________

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

Re: Failure with fork()

[marco atzeri]

Il 6/27/2013 8:35 PM, Alan W. Irwin ha scritto:
> I have been following this thread with great interest via the archive,
> but now I have newly subscribed to this list to ask additional
> questions.
>
> Corinna said "Should be fixed in CVS.  Thanks (to Arjen) for the report."
>
> My thanks to Arjen for getting this thread started, and
> my thanks to Corinna for so swiftly finding the fix.
>
> I would now like to test this fix from a broader perspective of
> attempting to run the fixed setup.exe version on Wine.
>
> My background is I have had considerable success with using the
> combination of MinGW, MSYS, and Wine as a build and test platform for
> free software.  I would like to similarly attempt to use the
> combination of Cygwin and Wine as a build and test platform for free
> software but I was stopped from doing that because the last stage of
> running Cygwin setup.exe on Wine ran into this fork issue.
>
> The only Windows platform available to me is Wine.  And I have
> no Cygwin on Wine experience at this stage because this fork bug shut
> me out.  But now that it is fixed in CVS, how do I get access to
> the fixed version of setup.exe?
>
> Are there daily snapshot builds of the CVS version I could access?

daily not, but on reasonable schedule
(aka when Corinna or Christopher release one)

http://cygwin.com/snapshots/

just wait for the next cygwin1-20130xxx.dll.bz2
and replace the installed cygwin1.dll with the new one

>
> Or do I have to build the CVS version of Cygwin from scratch on (the
> Wine version of) Windows using MinGW and MSYS, and if so is there a
> website with directions for how to do that?
>
> Sorry for the Cygwin newbie questions, but I am quite experienced with
> the Unix command line and building software both on Linux and on the
> bash.exe command line accessible with MinGW/MSYS/Wine so I hope I will
> only need hints to get started with (a) building the CVS version
> of Cygwin with the fork fix, and (b) building and testing software for
> the Cygwin on Wine platform.
>
> Alan
> __________________________
> Alan W. Irwin
>

Regards
Marco


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

Re: Failure with fork()

[Alan W. Irwin]

I have been following this thread with great interest via the archive,
but now I have newly subscribed to this list to ask additional
questions.

Corinna said "Should be fixed in CVS.  Thanks (to Arjen) for the report."

My thanks to Arjen for getting this thread started, and
my thanks to Corinna for so swiftly finding the fix.

I would now like to test this fix from a broader perspective of
attempting to run the fixed setup.exe version on Wine.

My background is I have had considerable success with using the
combination of MinGW, MSYS, and Wine as a build and test platform for
free software.  I would like to similarly attempt to use the
combination of Cygwin and Wine as a build and test platform for free
software but I was stopped from doing that because the last stage of
running Cygwin setup.exe on Wine ran into this fork issue.

The only Windows platform available to me is Wine.  And I have
no Cygwin on Wine experience at this stage because this fork bug shut
me out.  But now that it is fixed in CVS, how do I get access to
the fixed version of setup.exe?

Are there daily snapshot builds of the CVS version I could access?

Or do I have to build the CVS version of Cygwin from scratch on (the
Wine version of) Windows using MinGW and MSYS, and if so is there a
website with directions for how to do that?

Sorry for the Cygwin newbie questions, but I am quite experienced with
the Unix command line and building software both on Linux and on the
bash.exe command line accessible with MinGW/MSYS/Wine so I hope I will
only need hints to get started with (a) building the CVS version
of Cygwin with the fork fix, and (b) building and testing software for
the Cygwin on Wine platform.

Alan
__________________________
Alan W. Irwin

Astronomical research affiliation with Department of Physics and Astronomy,
University of Victoria (astrowww.phys.uvic.ca).

Programming affiliations with the FreeEOS equation-of-state
implementation for stellar interiors (freeeos.sf.net); the Time
Ephemerides project (timeephem.sf.net); PLplot scientific plotting
software package (plplot.sf.net); the libLASi project
(unifont.org/lasi); the Loads of Linux Links project (loll.sf.net);
and the Linux Brochure Project (lbproject.sf.net).
__________________________

Linux-powered Science
__________________________

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