Re: Failure with fork()

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

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

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

[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()

[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()

[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()

[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()

[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() (Cygwin on Wine install now sort of works)

[Alan W. Irwin]

[-- Attachment #1: Type: TEXT/PLAIN, Size: 4867 bytes --]

Here is my take on the current status of Cygwin on Wine:

At http://bugs.winehq.org/show_bug.cgi?id=24018, Andrey Turkin took
advantage of the recent Cygwin fork fix to provide an additional Wine
fix (the small self-described "hackish" patch he gives there) that
allowed setup.exe to complete without run-time issues (albeit with
some non-zero return codes from the post-install scripts which I will
discuss in more detail below).

I would like to thank Achim Gratz for his suggestion in this thread of how to
correctly update cygwin1.dll in the middle of a setup.exe run.  I
have implemented his suggestion as the (MSYS or Linux) bash script
replace_cygwin1.dll.sh which is contained in the attached tarball
along with associated setup.exe results.

Here is how I used that script in practice

On Linux:

# Clean out previous Cygwin results completely
rm -rf cygwin cygwin_packages

# Clean startup of wine-1.6-rc4 built with patch mentioned above.
# Normally does nothing, but sometimes the -k option kills something
# that is left over from a previous wine run.
wineserver -k
# Start wine server
wineserver -p
# Start Wine in a bash environment
wineconsole --backend=curses MinGW-4.7.2/msys/1.0/bin/bash.exe

# From now on we are in the MSYS base on Wine environment.

# Set PATH to point to MSYS (so that the bash script below will run) then
# run
bash.exe-3.1$ ./setup.exe -n -N -d -R /z/home/wine/newstart/cygwin \
-l /z/home/wine/newstart/cygwin_packages \
-s ftp://mirror.cpsc.ucalgary.ca /cygwin.com -D >setup_download.out

bash.exe-3.1$ ./replace_cygwin1.dll.sh \
cygwin1-20130627.dll cygwin_packages

bash.exe-3.1$ ./setup.exe -n -N -d -R /z/home/wine/newstart/cygwin \
-l /z/home/wine/newstart/cygwin_packages \
-s ftp://mirror.cpsc.ucalgary.ca /cygwin.com -L >setup_install.out

The resulting setup_download.out and setup_install.out files are
contained in the attached tarball along with the
replace_cygwin1.dll.sh script.  I should also mention that
cygwin1-20130627.dll (which contains the latest fork fix) was
downloaded from the next to last Cygwin snapshot at
http://cygwin.com/snapshots/ and decompressed, and the version
of setup.exe that was run (downloaded a few days ago from
cygwin) is 2.774 according to its initial GUI.

I have used explicit setup.exe options above to be clear on exactly
what I did.  For all else available in the setup GUI, I just
took defaults such as not installing any additional packages, and
using the recommended system install rather than individual install.

The first "download" setup.exe invocation above had no obvious issues,
and similarly for the run of replace_cygwin1.dll.sh.  (For the latter
case I double checked that cygwin1-20130627.dll was identical to
cygwin/bin/cygwin1.dll, i.e, the script worked properly).

The second "install from local directory" setup.exe invocation above
completed without run-time issues.  (The first post-install script
hangs indefinitely without the Andrey Turkin patch to Wine mentioned
above.) However, there were 4 post-install scripts that generated
non-zero return codes.  Would someone take a look at setup_install.out
in the attached tarball to see how serious they are?  I have no idea
about that question myself.  They could be evidence of Wine issues (or
Cygwin issues that are also seen on Microsoft Windows) or they could
just be for the most part normal startup "chatter" when attempting to
install Cygwin for the very first time that will go away for
subsequent Cygwin use after this initial installation.  The only one
of the messages that seems obviously serious is

rebase: failed to rename "/etc/rebase.db.RIRMJ5" to "/etc/rebase.db.i386":
Invalid request code
Manually rename "/etc/rebase.db.RIRMJ5" to "/etc/rebase.db.i386",
otherwise the new rebase database will be unusable.

So if the consensus here after looking at the setup_install.out
results is that cygwin on Wine is more or less installed properly from
these results (except for the rename issue above which I can fix by
doing that rename manually as suggested by the error message), then
the next order of business is to attempt to actually use that shiny
new Cygwin install, but I will reserve my absolutely Cygwin newbie
questions about how to do that for a different thread.

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
__________________________

[-- Attachment #2: compressed tarball containing replace_cygwin1.dll.sh and setup.exe results --]
[-- Type: APPLICATION/x-gtar-compressed, Size: 44888 bytes --]

[-- Attachment #3: Type: text/plain, Size: 218 bytes --]

--
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() (Cygwin on Wine install now sort of works)

[Alan W. Irwin]

On 2013-07-04 13:39-0700 Alan W. Irwin wrote:

> So if the consensus here after looking at the setup_install.out
> results is that cygwin on Wine is more or less installed properly from
> these results (except for the rename issue above which I can fix by
> doing that rename manually as suggested by the error message), then
> the next order of business [...]

I have now looked more carefully at the setup_install.out results that
are wrapped inside a tarball I attached to a previous post in this
thread.  At the same time I have also looked at the resulting files in
my cygwin install tree.  It turns out that because of errors the first
install script created an empty /etc/fstab rather than the desired
result and also was unable to create the /dev directory. These issues
very likely had follow-on effects for several of the other postinstall
scripts that were run (for example, all the read-only filesystem error
messages when any attempt was made to write to /dev.) Anyhow, it now
seems likely there are at least a couple of Wine bugs that are still
preventing a clean postinstall phase for setup.exe on Wine, and the
rest of this story will continue for now at
http://bugs.winehq.org/show_bug.cgi?id=24018.  Meanwhile, I thank the
people here that (a) helped to fix the Cygwin fork bug, and (b) gave
me good directions for trying out that fix before it becomes part of
an official Cygwin release.

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() (Cygwin on Wine install now sort of works)

[Christopher Faylor]

On Fri, Jul 05, 2013 at 12:11:10PM -0700, Alan W. Irwin wrote:
>On 2013-07-04 13:39-0700 Alan W. Irwin wrote:
>
>> So if the consensus here after looking at the setup_install.out
>> results is that cygwin on Wine is more or less installed properly from
>> these results (except for the rename issue above which I can fix by
>> doing that rename manually as suggested by the error message), then
>> the next order of business [...]
>
>I have now looked more carefully at the setup_install.out results that
>are wrapped inside a tarball I attached to a previous post in this
>thread.  At the same time I have also looked at the resulting files in
>my cygwin install tree.  It turns out that because of errors the first
>install script created an empty /etc/fstab rather than the desired
>result and also was unable to create the /dev directory.

The /dev directory is a pseudo-directory created on-the-fly by the
Cygwin DLL.

cgf

--
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() (Cygwin on Wine install now sort of works)

[Christopher Faylor]

On Fri, Jul 05, 2013 at 07:27:04PM -0700, Alan W. Irwin wrote:
>On 2013-07-05 16:48-0400 Christopher Faylor wrote:
>>On Fri, Jul 05, 2013 at 12:11:10PM -0700, Alan W.  Irwin wrote:
>>>On 2013-07-04 13:39-0700 Alan W.  Irwin wrote:
>>>>So if the consensus here after looking at the setup_install.out results
>>>>is that cygwin on Wine is more or less installed properly from these
>>>>results (except for the rename issue above which I can fix by doing
>>>>that rename manually as suggested by the error message), then the next
>>>>order of business [...]
>>>
>>>I have now looked more carefully at the setup_install.out results that
>>>are wrapped inside a tarball I attached to a previous post in this
>>>thread.  At the same time I have also looked at the resulting files in
>>>my cygwin install tree.  It turns out that because of errors the first
>>>install script created an empty /etc/fstab rather than the desired
>>>result and also was unable to create the /dev directory.
>>
>>The /dev directory is a pseudo-directory created on-the-fly by the
>>Cygwin DLL.
>
>I was really curious about the implications of that so had some further
>questions, but I am going to drop those questions because they are a
>distraction from the principal point I want to make.
>
>In sum, if any Cygwin developer here feels moved to help debug Wine so
>that the Cygwin install works properly on it, the best thing you could

I can only speak for this Cygwin developer but I have a long track
record of not wanting to involve myself in Cygwin and Wine interactions.
We stand on our head and do backflips in Cygwin code to get it to
emulate Linux behavior.  Having to do the same in another direction,
figuring out why something which works on multiple Windows platforms
does not work on a Windows emulator, is not something that I'm keen on
doing.

I'm just mentioning this in case you thought that since I have
sporadically been responding to this thread I might be interested in
joining in the discovery.  Unfortunately, I'm really not.

cgf

--
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() (Cygwin on Wine install now sort of works)

[Alan W. Irwin]

On 2013-07-05 16:48-0400 Christopher Faylor wrote:

> On Fri, Jul 05, 2013 at 12:11:10PM -0700, Alan W. Irwin wrote:
>> On 2013-07-04 13:39-0700 Alan W. Irwin wrote:
>> 
>>> So if the consensus here after looking at the setup_install.out
>>> results is that cygwin on Wine is more or less installed properly from
>>> these results (except for the rename issue above which I can fix by
>>> doing that rename manually as suggested by the error message), then
>>> the next order of business [...]
>> 
>> I have now looked more carefully at the setup_install.out results that
>> are wrapped inside a tarball I attached to a previous post in this
>> thread.  At the same time I have also looked at the resulting files in
>> my cygwin install tree.  It turns out that because of errors the first
>> install script created an empty /etc/fstab rather than the desired
>> result and also was unable to create the /dev directory.
> 
> The /dev directory is a pseudo-directory created on-the-fly by the
> Cygwin DLL.

I was really curious about the implications of that so had some further
questions, but I am going to drop those questions because they are a
distraction from the principal point I want to make.

In sum, if any Cygwin developer here feels moved to help debug Wine so
that the Cygwin install works properly on it, the best thing you could
do would be to follow the steps I detailed at at
<http://bugs.winehq.org/show_bug.cgi?id=24018>) with Wine-1.6-rc4
patched with Andrey Turkin's patch, and with Cygwin updated with the
recent snapshot cygwin1.dll that contains the fork fix.  Then run that
exact same setup.exe procedure (with the fork fix applied in the same
way) on Microsoft Windows.  Such direct comparisons between Wine and
Microsoft Windows results would be a great help in figuring out which
of the many error messages that show up in a fresh install of Cygwin
on Wine should actually be of concern to Wine developers.  (I cannot
do such comparisons myself because I don't have ready access to
Microsoft Windows, i.e., I have been running Linux since 1996 and my
only Windows experience is running MinGW/MSYS on Wine off and on as a
build and test platform for software for the last couple of years).

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() (Cygwin on Wine install now sort of works)

[Alan W. Irwin]

[-- Attachment #1: Type: TEXT/PLAIN, Size: 1994 bytes --]

Addendum.  I just noticed the request for cygcheck results at
http://cygwin.com/problems.html.  Accordingly,

I put /z/home/wine/newstart/cygwin/bin at the top of my
MSYS (on Wine) PATH, then executed

bash.exe-3.1$ cygcheck.exe -s -v -r >cygcheck.out

That generated a response to the terminal which was

cygcheck: Wrong architecture. Only ix86 executables supported.

For the record, I am using 32-bit Cygwin on 32-bit Wine on 64-bit
(x86_64) hardware.  My Linux platform is Debian wheezy with mostly
64-bit libraries installed, but 32-bit Wine was built specifically
with some extra 32-bit libraries I specifically installed for that
purpose.  So I don't know the source of that interesting message.
Note, that message occurs for the part of the cygchek results that
depend on cygwin1.dll.  If I fail to put cygwin/bin on my PATH,
then cygcheck complains that cygwin1.dll is not available but also
does not generate the above message.

I attach the cygcheck.out file generated as above in case somebody can
spot anything wrong in that report with my initial Cygwin on Wine
install. But superficially, it looks OK to me so it is possible that
my Cygwin on Wine installation is fine.

Note, my original message to this list with plain cygcheck.out
attached (as requested on the problems page) bounced for some reason
so I am trying a compressed version of cygcheck.out this time.

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
__________________________

[-- Attachment #2: compressed output from cygcheck for Cygwin on Wine --]
[-- Type: APPLICATION/x-gtar-compressed, Size: 3575 bytes --]

[-- Attachment #3: Type: text/plain, Size: 218 bytes --]

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