Re: fork() fails if it is called recursively from a child thread.

[Takashi Yano]

Hello,

On Fri, 10 Mar 2017 21:10:36 +0100 Corinna Vinschen wrote:
> Thanks for the report and especially the testcase.
> 
> It was a tricky problem to debug so it took me a while, but I think
> I got it now.
> 
> I uploaded new developer snapshots to https://cygwin.com/snapshots/
> 
> Please give them a try.  I'd be also interested if that fixes the iperf
> problem.  Can you check?  There's always a chance that this uncovers
> another problem hidden under this one...

I tested the new snapshot, and confirmed the issue was fixed.
The test case as well as iperf 2.0.5 with options -s -D works
without problem.

At least in my short test, I couldn't find any other hidden
problems.

Thank you very much!

-- 
Takashi Yano 

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

cygtls crash causing twisted 13.2 app to livelock?

[Dan Kegel]

Hi folks,
I've had a buildbot worker running on cygwin for the last few
years.  The python program occasionally appears to busy-hang
after forking a git, regardless of version of windows or
up-to-dateness or 32/64 bitness of cygwin.
More details at http://trac.buildbot.net/ticket/3670
Today it happened at the same time on both win7 and win10,
so I'm starting to get motivated to understand it.
Chances are it's just a bug in twisted 13.2 (which is
pretty old), but I did see something interesting:

strace of the livelocked python shows the following output repeatedly:

-- Process 8232, exception c005 at 000180042C51
   55 2120509 [flasio] python 9276 exception::handle: In
cygwin_except_handler exception 0xC005 at 0x180042C51 sp 0x275CB60
   32 2120541 [flasio] python 9276 exception::handle: In
cygwin_except_handler signal 11 at 0x180042C51
   72 2120613 [flasio] python 9276 _cygtls::inside_kernel: pc
0x180042C51, h 0x18004, inside_kernel 0
   40 2120653 [flasio] python 9276 seterrno_from_nt_status:
/home/corinna/src/cygwin/cygwin-2.6.0/cygwin-2.6.0-1.x86_64/src/newlib-cygwin/winsup/cygwin/fhandler_mailslot.cc:132
status 0xC034 -> windows error 2
   30 2120683 [flasio] python 9276 geterrno_from_win_error: windows
error 2 == errno 2
   30 2120713 [flasio] python 9276 sig_send: sendsig 0xC4, pid 9276,
signal 11, its_me 1
   28 2120741 [flasio] python 9276 sig_send: wakeup 0x42C
   32 2120773 [sig] python 9276 sigpacket::process: signal 11 processing
   19 2120792 [sig] python 9276 sigpacket::process: signal 11 blocked
   18 2120810 [sig] python 9276 sigpacket::process: returning -1
   22 2120832 [sig] python 9276 wait_sig: signalling pack.wakeup 0x42C
   24 2120856 [flasio] python 9276 sig_send: Waiting for pack.wakeup 0x42C
   30 2120886 [flasio] python 9276 sig_send: returning 0x0 from
sending signal 11

Attaching with gdb and doing 'info threads' and 'bt N' on each thread
until I found a related-looking thread showed:

#0  0x7ffbd845386a in ntdll!ZwWaitForSingleObject ()
   from /cygdrive/c/Windows/SYSTEM32/ntdll.dll
#1  0x7ffbd51e415f in WaitForSingleObjectEx ()
   from /cygdrive/c/Windows/system32/KERNELBASE.dll
#2  0x00018011f027 in sig_send(_pinfo*, siginfo_t&, _cygtls*) ()
from /usr/bin/cygwin1.dll
#3  0x00018005c7c1 in exception::handle(_EXCEPTION_RECORD*, void*,
_CONTEXT*, _DISPATCHER_CONTEXT*) () from /usr/bin/cygwin1.dll
#4  0x7ffbd845666d in ntdll!.chkstk () from
/cygdrive/c/Windows/SYSTEM32/ntdll.dll
#5  0x7ffbd83d3c00 in ntdll!RtlWalkFrameChain () from
/cygdrive/c/Windows/SYSTEM32/ntdll.dll
#6  0x7ffbd845577a in ntdll!KiUserExceptionDispatcher ()
   from /cygdrive/c/Windows/SYSTEM32/ntdll.dll
#7  0x000180042c51 in _cfree () from /usr/bin/cygwin1.dll
#8  0x0001801deab3 in fhandler_pipe::~fhandler_pipe() () from
/usr/bin/cygwin1.dll
#9  0x0001800621f5 in flush_async_io(void*) () from /usr/bin/cygwin1.dll
#10 0x000180044753 in cygthread::callfunc(bool) () from /usr/bin/cygwin1.dll
#11 0x000180044cea in cygthread::stub(void*) () from /usr/bin/cygwin1.dll
#12 0x000180045733 in _cygtls::call2(unsigned int (*)(void*,
void*), void*, void*) ()
   from /usr/bin/cygwin1.dll
#13 0x0001800457e4 in _cygtls::call(unsigned int (*)(void*,
void*), void*) ()
   from /usr/bin/cygwin1.dll
#14 0x7ffbd5e52d92 in KERNEL32!BaseThreadInitThunk ()
   from /cygdrive/c/Windows/system32/KERNEL32.DLL
#15 0x7ffbd83c9f64 in ntdll!RtlUserThreadStart ()
   from /cygdrive/c/Windows/SYSTEM32/ntdll.dll

An exception in chkstk in a thread that looks like it's cygwin's baby
seemed interesting enough to report.

I'll attach the output of cygcheck and gdb.
(gdb) info threads
  Id   Target Id Frame
  9Thread 14024.0x264c 0x7ffbd84553e1 in ntdll!DbgBreakPoint ()
   from /cygdrive/c/Windows/SYSTEM32/ntdll.dll
  8Thread 14024.0x3e34 0x7ffbd845538a in 
ntdll!ZwWaitForWorkViaWorkerFactory ()
   from /cygdrive/c/Windows/SYSTEM32/ntdll.dll
  7Thread 14024.0x1064 0x7ffbd845386a in ntdll!ZwWaitForSingleObject ()
   from /cygdrive/c/Windows/SYSTEM32/ntdll.dll
  6Thread 14024.0x1f60 0x7ffbd845386a in ntdll!ZwWaitForSingleObject ()
   from /cygdrive/c/Windows/SYSTEM32/ntdll.dll
  5Thread 14024.0x2088 0x7ffbd845386a in ntdll!ZwWaitForSingleObject ()
   from /cygdrive/c/Windows/SYSTEM32/ntdll.dll
  4Thread 14024.0x1e64 0x7ffbd8453dda in ntdll!ZwWaitForMultipleObjects 
()
   from /cygdrive/c/Windows/SYSTEM32/ntdll.dll
  3Thread 14024.0xa14 0x7ffbd845386a in ntdll!ZwWaitForSingleObject ()
   from /cygdrive/c/Windows/SYSTEM32/ntdll.dll
  2Thread 14024.0x3628 0x7ffbd845388a in ntdll!ZwReadFile ()
   from /cygdrive/c/Windows/SYSTEM32/ntdll.dll
* 1Thread 14024.0x708 0x7ffbd845386a in ntdll!ZwWaitForSingleObject ()
   from /cygdrive/c/Windows/SYSTEM32/ntdll.dll
(gdb) thread 1
[Switching to thread 1 (Thread 14024.0x708)]
#0  0x7ffbd845386a in ntdll!ZwWaitForSingleObject ()
   from 

Re: [SECURITY] libidn - locale specific error in test suite

[Yaakov Selkowitz]

On 2017-02-22 12:58, Yaakov Selkowitz wrote:

On 2017-01-19 14:42, Yaakov Selkowitz wrote:

On 2017-01-03 04:53, Dr. Volker Zell wrote:

Just tried packaging libidn-1.33 and found a locale specific error in
the test suite (Which was working fine with my latest build). When
running under strace I get:


Dr. Volker,

Since the bug discovered by this test is unrelated to libidn itself,
there should be no need to hold back the libidn release therefor.


Ping?


Ping 2?

--
Yaakov

Re: [SECURITY] libidn - locale specific error in test suite

[Yaakov Selkowitz]

On 2017-02-22 12:58, Yaakov Selkowitz wrote:

On 2017-01-19 14:42, Yaakov Selkowitz wrote:

On 2017-01-03 04:53, Dr. Volker Zell wrote:

Just tried packaging libidn-1.33 and found a locale specific error in
the test suite (Which was working fine with my latest build). When
running under strace I get:


Dr. Volker,

Since the bug discovered by this test is unrelated to libidn itself,
there should be no need to hold back the libidn release therefor.


Ping?


Ping 2?

--
Yaakov

Re: [SECURITY] gnutls

[Yaakov Selkowitz]

On 2017-02-22 12:46, Yaakov Selkowitz wrote:

On 2016-09-26 14:13, Yaakov Selkowitz wrote:

On 2016-09-26 02:00, Yaakov Selkowitz wrote:

Dr. Volker,

Two security issues have been reported in GnuTLS:

https://www.gnutls.org/security.html#GNUTLS-SA-2016-2
https://www.gnutls.org/security.html#GNUTLS-SA-2016-3

At this point, I think the best way to proceed would be to:

1) release 3.3.24 with the patch for the latter, then;
2) update to 3.4.15, which involves an ABI break.


nettle is also overdue for an update (it's also blocking an update to
filezilla); getting that in after 3.3.24 and prior to 3.4 would be best.


Ping?  More vulnerabilities have been announced, so we need to revise
the above to 3.3.26 and 3.5.9.


Ping 2?

--
Yaakov

Junctions != Symlinks; Treat Junctions as MS-FS mounts; MS-symlinks are symlinks

[L A Walsh]

Andrey Repin wrote:

 Greetings, L A Walsh!

> Andrey Repin wrote:
>> I would argue against all junctions being treated blindly.
>> The difference with bind mounts in Linux is that in Linux
>> you don't have the
>> information available within the filesystem itself, and have
>> no other option,
>> than to treat them as regular directories.
>> Only direct volume junctions cause an issue, and this is what
>> should be fixed,
>> if possible, not sidetracked with questionable workarounds.
> 
> Could you describe the benefits of your proposed solution?

> You do know that MS originally called junctions "mountpoints",
> right?  So why would cygwin treating them as such be a "questionable
> workaround"?

 How they are called, and how they behave is a two different questions.

> How would you want to treat them?
> Could you describe the benefits of your proposed solution?

 Easy way: As symlinks, just like now, unless it's a volume
 mount point that can't be normalized to a disk letter.


   You say that throwing out the MS-designed ability
to mount a filesystem subtree and treat them the same as another
feature they added, "symlinks", is a benefit?

   Sorry.  But throwing out useful features is not
a benefit.  I asked for a benefit.  MS designed JUNCTIONS as
'bind' mountpoints.  That was an added feature added in WinXP
and Windows2000.

   They added symlinks in Vista to create a feature,
similar to *nix symlinks.  I don't see how throwing out mount
points is anything but a BUG -- a removal of a useful feature.

   I want to be able to mount other areas of other file
systems onto directories.  Symlinks are destroyed by Cygwin's
SETUP.EXE and the install process For example.  I have
a smallish "/usr" partition, but a large "/Users" partition.
"/usr/share" grew to hold more and more data over time, and
currently is using 16G, all by itself.  My "/usr" partition is
15GB with 4.7GB free, 11G used.  So I needed to split
"/usr/share" off to somewhere else.  I don't have room for another
drive, but I do have room on "/Users".  So tell me,
why shouldn't I be able to create "/Users/share" and mount
"/Users/share" at "/usr/share"?

   Same problem under "/opt" under linux.  "/opt" is
a directory on my root partition.  When I wanted to
install "VirtualBox" (which lives under "/opt/VirtualBox" it
refused to run from a path that had a symlink in it.  How
would you solve that?

   I used a 'bind' mount.  VirtualBox rejected
symlinks in its base path, but it does work with mounted
filesystems.

   In the same way, not only Cygwin's "setup.exe"
but also many of the "install" scripts that install programs
under cygwin, check to see if there is a symlink as part
of their base path.  If they find one -- they remove it
and re-create the directory where there used to be a
symlink.  Result: "/usr/share/man/man1/newprog1.gz"
s all alone under 'man' as "/usr/share/info/newprog.gz"
is by itself under /usr/share/info.   Where did the rest
of my files go?

   They are still there -- but under
"/Users/share/...".  That's my main problem.  Cygwin
doesn't install things in "/usr/share//"
But first, removes all existing symlinks in its base
path.

   Without the ability to mount /Users/share
(or /Users/opt) at /usr/share and /usr/opt, I have
no way to manage the space on my devices.

   So how would a Windows or Linux user solve
the problem?  They'd use the OS's built-in 'bind-mount'
feature (called 'junction' in MS-speak).  Because
junctions are meant to be a way of splicing part of
one file system into another at a specific path.



 Preferred way: Fix volume mounts accessibility
 \\?\{UUID} -> /dev/disk/by-uuid/UUID


   Sorry, but \\? is not a valid Windows path:

 ll //?/

ls: cannot access //?/: No such file or directory

/> cmd
C:\>dir \\?\
dir \\?\
The filename, directory name, or volume label syntax is incorrect.

Your suggestion doesn't work under windows, but
JUNCTIONS do work under windows:

C:\>dir \var
dir \var
Volume in drive C is System Disk
Volume Serial Number is E889-68E4

Directory of C:\var

03/06/2017  12:35 AM  .
03/06/2017  12:35 AM  ..
10/24/2015  10:20 PM  cache
07/11/2015  10:22 PM  cron
10/11/2014  07:17 AM  empty
09/18/2014  03:57 PM  games
01/11/2017  03:29 PM  lib
03/06/2017  12:29 AM21,767,776 locatedb
01/12/2017  07:03 AM  log
01/29/2017  11:59 PM  run
01/29/2017  10:06 PM65,536 syslog-ng.persist
01/17/2017  03:15 PM 5 syslog-ng.pid
03/06/2017  12:29 AM  tmp
04/28/2014  11:34 AM  varnish
  3 File(s) 21,833,317 bytes
C:\>dir \|grep var
dir \|grep var
01/11/2017  04:17 PM var [C:\Users\cyg_var]

-
Show me how I can create a path that must have
symlinks in it, that won't be removed or changed
by cygwin's setup or other cygwin programs.

With JUNCTIONs as a mount point, 

Re: Providing/Packaging a Postinstalled SUSV4 Doc only Package a la Debian

[David Stacey]

On 10/03/17 20:24, Achim Gratz wrote:

Corinna Vinschen writes:

Otherwise, I am nervous about setting a precedent for a package that could
give different contents each time it is installed (yes, Microsoft, I'm
looking at you too). And there are plenty of corner cases where this
wouldn't work: offline installs, web proxies, or if the account performing
the Cygwin install (e.g. Administrator) was blocked from accessing the web
(on security grounds).

This is another interesting point of course.  Does wget or curl allow
to specify a (short) timeout before giving up and just not installing
anything, perhaps?


Yes. 'wget' has --timeout=. You can also set --dns-timeout, 
--connect-timeout and --read-timeout for fine-grain control [1]. 
However, the defaults are sensible and it gives up fairly quickly if 
there's no network.


'curl' has --max-time and --connect-timeout [2].


Regardless if that is possible (I think it is), I would not accept such
a package into the standard distribution.  For one, setup is not really
equipped to handle such packages properly.  Two, I really can't allow
anything to download something from outside the internal network during
the installation even where it might work.


I agree completely. I maintain what is effectively a private corporate 
Cygwin Time Machine, so the company I work for can recreate 
installations. Having this kind of repeatability is important to some 
people. In one sense I can't get too excited - it's just a documentation 
package afterall - I'm just nervous that it sets a precedent. What's 
next? Similar packages for non-free fonts? How about a package that 
downloads the 'lame' source, builds it and installs it, all from a 
post-install script? These might sound a bit extreme, but you get my point.


Dave.

[1] - https://linux.die.net/man/1/wget
[2] - https://linux.die.net/man/1/curl

Re: Strange errors running gcc tests on Cygwin

[Achim Gratz]

Brian Inglis writes:
> Has that been released yet or is it implied in options -O --oblivious 
> and -T --filelist=FILE as documented in NEWS?

Yes, -O is the option I was talking about (it now also implies -s, so
you don't need explicitly say that).  The typical use would be with -T
as you say, maybe feeding in the list of files from a pipe:

find … | rebase -OT -


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

Wavetables for the Waldorf Blofeld:
http://Synth.Stromeko.net/Downloads.html#BlofeldUserWavetables

--
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: Strange errors running gcc tests on Cygwin

[Brian Inglis]

On 2017-03-10 11:56, Achim Gratz wrote:
> Brian Inglis writes:
>> Ensure that all Cygwin dlls including anything you build are
>> included in every rebase, and do an incremental rebase after every
>> build. 
> Don't do this, it's not what incremental rebase is for. I've 
> specifically implemented the "ephemeral" option to rebase to
> temporarily deal with DLL in staging directories without polluting
> the global rebase map. The rebase map is still used if you specify
> that in order to work around the address space used by the
> installation, but the newl rebased libraries don't get recorded
> there. Since that rebase is throw-away you have to specify all the
> ephemeral DLL that can potentially collide in each invocation of
> rebase. That's still easier than doing a full rebase once you're done
> building.

Has that been released yet or is it implied in options -O --oblivious 
and -T --filelist=FILE as documented in NEWS?

$ uname -srvmo
CYGWIN_NT-10.0 2.7.0(0.306/5/3) 2017-02-12 13:18 x86_64 Cygwin
$ rebase --version
rebase version 4.4.2 (imagehelper version 0.11)

-- 
Take care. Thanks, Brian Inglis, Calgary, Alberta, Canada

--
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: [PATCH] forkables: hardlink without WRITE_ATTRIBUTES first

[Corinna Vinschen]

On Mar 10 11:32, Michael Haubenwallner wrote:
> When the current process has renamed (to bin) a readonly dll, we get
> STATUS_TRANSACTION_NOT_ACTIVE for unknown reason when subsequently
> creating the forkable hardlink. A workaround is to open the original
> file with FILE_WRITE_ATTRIBUTES access, but that fails with permission
> denied for users not owning the original file.
> 
> * forkable.cc (dll::create_forkable): Retry hardlink creation using the
> original file's handle opened with FILE_WRITE_ATTRIBUTES access when the
> first attempt fails with STATUS_TRANSACTION_NOT_ACTIVE.

Patch applied to topic/forkables (which I rebased so pull -f).

I'm planning to make a 2.8.0 release and then pull over the forkables
stuff to master for the next release.  Maybe we should bump the DLL
version to 3.0 then.  It's a pretty big functionality extension...


Thanks,
Corinna

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


signature.asc
Description: PGP signature

Re: Providing/Packaging a Postinstalled SUSV4 Doc only Package a la Debian

[Achim Gratz]

Corinna Vinschen writes:
>> Otherwise, I am nervous about setting a precedent for a package that could
>> give different contents each time it is installed (yes, Microsoft, I'm
>> looking at you too). And there are plenty of corner cases where this
>> wouldn't work: offline installs, web proxies, or if the account performing
>> the Cygwin install (e.g. Administrator) was blocked from accessing the web
>> (on security grounds).
>
> This is another interesting point of course.  Does wget or curl allow
> to specify a (short) timeout before giving up and just not installing
> anything, perhaps?

Regardless if that is possible (I think it is), I would not accept such
a package into the standard distribution.  For one, setup is not really
equipped to handle such packages properly.  Two, I really can't allow
anything to download something from outside the internal network during
the installation even where it might work.


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

SD adaptations for Waldorf Q V3.00R3 and Q+ V3.54R2:
http://Synth.Stromeko.net/Downloads.html#WaldorfSDada

Re: fork() fails if it is called recursively from a child thread.

[Corinna Vinschen]

Hi,

On Mar  9 20:39, Takashi Yano wrote:
> Hello,
> 
> I found fork() fails if it is called recursively from a child thread.
> 
> Simple test case, attached (fk.c), reproduces this problem.
> 
> Expected result:
> Parent 0 [22034] exit.
> Child 0 [22036] works.
> Parent 1 [22036] exit.
> Child 1 [22038] works.
> Parent 2 [22038] exit.
> Child 2 [22039] works.
> Parent 3 [22039] exit.
> Child 3 [22040] works.
> Parent 4 [22040] exit.
> Child 4 [22041] works.
> 
> Result in cygwin 2.7.0:
> Child 0 [4668] works.
> Parent 0 [7188] exit.
>   0 [main] a 4668 fork: child -1 - forked process 8456 died unexpectedly, 
> retry 0, exit code 0xC142, errno 11
> fork(): Resource temporarily unavailable
> 
> Strictly speaking, the test case is not safe because it calls functions
> which are not async-signal-safe from forked child process, i.e. printf()
> and perror(), in spite of multi-thread. However the same happens even
> without printf() and perror().
> 
> This is the cause of which iperf 2.0.5 with option -s -D fails to start
> as daemon.

Thanks for the report and especially the testcase.

It was a tricky problem to debug so it took me a while, but I think
I got it now.

I uploaded new developer snapshots to https://cygwin.com/snapshots/

Please give them a try.  I'd be also interested if that fixes the iperf
problem.  Can you check?  There's always a chance that this uncovers
another problem hidden under this one...


Thanks,
Corinna

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


signature.asc
Description: PGP signature

Re: Providing/Packaging a Postinstalled SUSV4 Doc only Package a la Debian

[Corinna Vinschen]

On Mar 10 15:43, David Stacey wrote:
> On 06/03/17 20:42, Brian Inglis wrote:
> > Debian provides a SUSV4 package which downloads the tar.bz2 and installs
> > the HTML tree from:
> > 
> > http://pubs.opengroup.org/onlinepubs/9699919799/download/
> > 
> > in the postinstall script, as they believe that complies with the terms
> > permitting individual download stated and linked at:
> > 
> > http://pubs.opengroup.org/onlinepubs/terms.htm
> > 
> > http://www.opengroup.org/legal
> > 
> > Is there any interest in such a package in Cygwin, and is this approach
> > acceptable?
> 
> Given that no-one else has replied:

Sorry for not replying earlier.  Yaakov asked our legel dept
for advice and the result is this:

It's ok if the package downloads the tar file and unpacks it in a
post-install script, provided that the user gets an opportunity to
see http://pubs.opengroup.org/onlinepubs/terms.htm prior to the
installation.

For that to accomplish it's sufficient if the user gets pointed to
that document at install time.  You can do this with an install
message.  In cygport, add something like

  MESSAGE="The content generated by this package is provided under the terms as 
outlined by http://pubs.opengroup.org/onlinepubs/terms.htm;

That will do it.

> Otherwise, I am nervous about setting a precedent for a package that could
> give different contents each time it is installed (yes, Microsoft, I'm
> looking at you too). And there are plenty of corner cases where this
> wouldn't work: offline installs, web proxies, or if the account performing
> the Cygwin install (e.g. Administrator) was blocked from accessing the web
> (on security grounds).

This is another interesting point of course.  Does wget or curl allow
to specify a (short) timeout before giving up and just not installing
anything, perhaps?


Corinna

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


signature.asc
Description: PGP signature

[newlib-cygwin] errno: Stop using _impure_ptr->_errno completely

[Corinna Vinschen]

https://sourceware.org/git/gitweb.cgi?p=newlib-cygwin.git;h=44b1746a41921533d27aca414a9188314cb725b6

commit 44b1746a41921533d27aca414a9188314cb725b6
Author: Corinna Vinschen 
Date:   Fri Mar 10 20:21:09 2017 +0100

errno: Stop using _impure_ptr->_errno completely

We use errno AKA _REENT->_errno since the last century and only set
_impure_ptr->_errno for backward compat.  Stop that.  Also, remove
the last check for _impure_ptr->_errno in Cygwin code.

Signed-off-by: Corinna Vinschen 

Diff:
---
 winsup/cygwin/cygerrno.h | 4 ++--
 winsup/cygwin/environ.cc | 3 +--
 winsup/cygwin/errno.cc   | 4 ++--
 3 files changed, 5 insertions(+), 6 deletions(-)

diff --git a/winsup/cygwin/cygerrno.h b/winsup/cygwin/cygerrno.h
index ce33d97..05de6ab 100644
--- a/winsup/cygwin/cygerrno.h
+++ b/winsup/cygwin/cygerrno.h
@@ -30,7 +30,7 @@ extern inline int
 __set_errno (const char *fn, int ln, int val)
 {
   debug_printf ("%s:%d setting errno %d", fn, ln, val);
-  return errno = _impure_ptr->_errno = val;
+  return errno = val;
 }
 #define set_errno(val) __set_errno (__PRETTY_FUNCTION__, __LINE__, (val))
 
@@ -45,7 +45,7 @@ class save_errno
 save_errno (int what) {saved = get_errno (); set_errno (what); }
 void set (int what) {set_errno (what); saved = what;}
 void reset () {saved = get_errno ();}
-~save_errno () {errno = _impure_ptr->_errno = saved;}
+~save_errno () {errno = saved;}
   };
 
 extern const char *__sp_fn;
diff --git a/winsup/cygwin/environ.cc b/winsup/cygwin/environ.cc
index 667e7c0..7d90e4f 100644
--- a/winsup/cygwin/environ.cc
+++ b/winsup/cygwin/environ.cc
@@ -454,8 +454,7 @@ posify_maybe (char **here, const char *value, char *outenv)
 
   memcpy (outenv, src, len);
   char *newvalue = outenv + len;
-  if (!conv->toposix (value, newvalue, NT_MAX_PATH - len)
-  || _impure_ptr->_errno != EIDRM)
+  if (!conv->toposix (value, newvalue, NT_MAX_PATH - len) || errno != EIDRM)
 conv->add_cache (newvalue, *value != '/' ? value : NULL);
   else
 {
diff --git a/winsup/cygwin/errno.cc b/winsup/cygwin/errno.cc
index 9168e9b..390723e 100644
--- a/winsup/cygwin/errno.cc
+++ b/winsup/cygwin/errno.cc
@@ -339,7 +339,7 @@ void __reg3
 seterrno_from_win_error (const char *file, int line, DWORD code)
 {
   syscall_printf ("%s:%d windows error %u", file, line, code);
-  errno = _impure_ptr->_errno =  geterrno_from_win_error (code, EACCES);
+  errno = geterrno_from_win_error (code, EACCES);
 }
 
 int __reg2
@@ -357,7 +357,7 @@ seterrno_from_nt_status (const char *file, int line, 
NTSTATUS status)
   SetLastError (code);
   syscall_printf ("%s:%d status %y -> windows error %u",
  file, line, status, code);
-  errno = _impure_ptr->_errno =  geterrno_from_win_error (code, EACCES);
+  errno = geterrno_from_win_error (code, EACCES);
 }
 
 static char *

[newlib-cygwin] _dll_crt0: Drop incorrect check for being started from parent main thread

[Corinna Vinschen]

https://sourceware.org/git/gitweb.cgi?p=newlib-cygwin.git;h=35d344babe154bde4e5dfcc01638251cc50e2e79

commit 35d344babe154bde4e5dfcc01638251cc50e2e79
Author: Corinna Vinschen 
Date:   Fri Mar 10 20:28:09 2017 +0100

_dll_crt0: Drop incorrect check for being started from parent main thread

This test was broken from the start.  It leads to creating a completely
new stack for the main thread of the child process when started from
the main thread of the parent.  However, the main thread of a process
can easily running on a completely different stack, if the parent's main
thread was created by calling fork() from a pthread.  For an example,
see https://cygwin.com/ml/cygwin/2017-03/msg00113.html

Signed-off-by: Corinna Vinschen 

Diff:
---
 winsup/cygwin/dcrt0.cc | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/winsup/cygwin/dcrt0.cc b/winsup/cygwin/dcrt0.cc
index 8ddee0c..ea6adcb 100644
--- a/winsup/cygwin/dcrt0.cc
+++ b/winsup/cygwin/dcrt0.cc
@@ -1041,7 +1041,7 @@ _dll_crt0 ()
  under our own control and avoids collision with the OS. */
   if (!dynamically_loaded)
 {
-  if (!in_forkee || fork_info->from_main)
+  if (!in_forkee)
{
  /* Must be static since it's referenced after the stack and frame
 pointer registers have been changed. */

[newlib-cygwin] Belatedly bump Cygwin DLL version to 2.8.0

[Corinna Vinschen]

https://sourceware.org/git/gitweb.cgi?p=newlib-cygwin.git;h=c9e4b69e9f48a517ec5c6bbf20c80bd744117b14

commit c9e4b69e9f48a517ec5c6bbf20c80bd744117b14
Author: Corinna Vinschen 
Date:   Fri Mar 10 20:50:35 2017 +0100

Belatedly bump Cygwin DLL version to 2.8.0

Signed-off-by: Corinna Vinschen 

Diff:
---
 winsup/cygwin/include/cygwin/version.h |  4 ++--
 winsup/cygwin/release/{2.7.1 => 2.8.0} |  3 +++
 winsup/doc/new-features.xml| 30 ++
 3 files changed, 35 insertions(+), 2 deletions(-)

diff --git a/winsup/cygwin/include/cygwin/version.h 
b/winsup/cygwin/include/cygwin/version.h
index 6023131..6ca3079 100644
--- a/winsup/cygwin/include/cygwin/version.h
+++ b/winsup/cygwin/include/cygwin/version.h
@@ -10,8 +10,8 @@ details. */
the Cygwin shared library".  This version is used to track important
changes to the DLL and is mainly informative in nature. */
 
-#define CYGWIN_VERSION_DLL_MAJOR 2007
-#define CYGWIN_VERSION_DLL_MINOR 1
+#define CYGWIN_VERSION_DLL_MAJOR 2008
+#define CYGWIN_VERSION_DLL_MINOR 0
 
 /* Major numbers before CYGWIN_VERSION_DLL_EPOCH are incompatible. */
 
diff --git a/winsup/cygwin/release/2.7.1 b/winsup/cygwin/release/2.8.0
similarity index 73%
rename from winsup/cygwin/release/2.7.1
rename to winsup/cygwin/release/2.8.0
index 43d9bd0..d8e20a1 100644
--- a/winsup/cygwin/release/2.7.1
+++ b/winsup/cygwin/release/2.8.0
@@ -20,3 +20,6 @@ What changed:
 Bug Fixes
 -
 
+- Fix a few problems which are the combined culprit of fork failing
+  when called recursively from a pthread.
+  Addresses: https://cygwin.com/ml/cygwin/2017-03/msg00113.html
diff --git a/winsup/doc/new-features.xml b/winsup/doc/new-features.xml
index ed68efb..185c97e 100644
--- a/winsup/doc/new-features.xml
+++ b/winsup/doc/new-features.xml
@@ -4,6 +4,36 @@
 
 What's new and what changed in Cygwin
 
+What's new and what changed in 2.8
+
+
+
+
+New API: timingsafe_bcmp, timingsafe_memcmp.
+
+
+
+New API: dladdr.
+
+
+
+Cygcheck and strace now always generate output with Unix LF line endings,
+rather than with DOS/Windows CR LF line endings.
+
+
+
+Fork now preserves the load order of unrelated dlopen'd modules.
+
+
+
+Pthread_cond_wait now acts like Linux and BSD: Resume waiting for the
+condition variable as if it was not interrupted, rather than returning 0.
+
+
+
+
+
+
 What's new and what changed in 2.7
 
 

[newlib-cygwin] Drop now unused child_info_fork::from_main

[Corinna Vinschen]

https://sourceware.org/git/gitweb.cgi?p=newlib-cygwin.git;h=45d0d759103cf00ce61aafe31769bf9de673f9cf

commit 45d0d759103cf00ce61aafe31769bf9de673f9cf
Author: Corinna Vinschen 
Date:   Fri Mar 10 20:45:19 2017 +0100

Drop now unused child_info_fork::from_main

Signed-off-by: Corinna Vinschen 

Diff:
---
 winsup/cygwin/child_info.h | 3 +--
 1 file changed, 1 insertion(+), 2 deletions(-)

diff --git a/winsup/cygwin/child_info.h b/winsup/cygwin/child_info.h
index 5c449e1..f7a1441 100644
--- a/winsup/cygwin/child_info.h
+++ b/winsup/cygwin/child_info.h
@@ -36,7 +36,7 @@ enum child_status
 #define EXEC_MAGIC_SIZE sizeof(child_info)
 
 /* Change this value if you get a message indicating that it is out-of-sync. */
-#define CURR_CHILD_INFO_MAGIC 0x30ea98f6U
+#define CURR_CHILD_INFO_MAGIC 0xc96f5e9U
 
 #define NPROCS 256
 
@@ -106,7 +106,6 @@ public:
   void *stackbase; // StackBase of parent thread
   size_t guardsize; // size of POSIX guard region or (size_t) -1 if
// user stack
-  bool from_main;  // true if started from parent's main thread
   char filler[4];
   child_info_fork ();
   void __reg1 handle_fork ();

[newlib-cygwin] fork: Don't copy _main_tls->local_clib from *_impure_ptr

[Corinna Vinschen]

https://sourceware.org/git/gitweb.cgi?p=newlib-cygwin.git;h=48755fb9bca8ae379a6f96619b8b7774ff4b4494

commit 48755fb9bca8ae379a6f96619b8b7774ff4b4494
Author: Corinna Vinschen 
Date:   Fri Mar 10 20:44:53 2017 +0100

fork: Don't copy _main_tls->local_clib from *_impure_ptr

So far we copy *_impure_ptr into _main_tls->local_clib if the child
process has been forked from a pthread.  But that's not required.
The local_clib area of the new thread is on the stack and the stack
gets copied from the parent anyway (in frok::parent).  So we only
have to make sure _main_tls is pointing to the right address and
do the simple post-fork thread init.

Signed-off-by: Corinna Vinschen 

Diff:
---
 winsup/cygwin/fork.cc | 9 ++---
 1 file changed, 2 insertions(+), 7 deletions(-)

diff --git a/winsup/cygwin/fork.cc b/winsup/cygwin/fork.cc
index ef5a268..73a72f5 100644
--- a/winsup/cygwin/fork.cc
+++ b/winsup/cygwin/fork.cc
@@ -143,15 +143,11 @@ frok::child (volatile char * volatile here)
myself->pid, myself->ppid, __builtin_frame_address (0));
   sigproc_printf ("hParent %p, load_dlls %d", hParent, load_dlls);
 
-  /* If we've played with the stack, stacksize != 0.  That means that
- fork() was invoked from other than the main thread.  Make sure that
- the threadinfo information is properly set up.  */
-  if (!fork_info->from_main)
+  /* Make sure threadinfo information is properly set up. */
+  if (&_my_tls != _main_tls)
 {
   _main_tls = &_my_tls;
   _main_tls->init_thread (NULL, NULL);
-  _main_tls->local_clib = *_impure_ptr;
-  _impure_ptr = &_main_tls->local_clib;
 }
 
   set_cygwin_privileges (hProcToken);
@@ -300,7 +296,6 @@ frok::parent (volatile char * volatile stack_here)
 
   ch.forker_finished = forker_finished;
 
-  ch.from_main = &_my_tls == _main_tls;
   ch.stackbase = NtCurrentTeb ()->Tib.StackBase;
   ch.stackaddr = NtCurrentTeb ()->DeallocationStack;
   if (!ch.stackaddr)

[newlib-cygwin] Drop redundant brackets in call to _reclaim_reent

[Corinna Vinschen]

https://sourceware.org/git/gitweb.cgi?p=newlib-cygwin.git;h=f2e6553c2528c2afe048366821725eb3ca26e044

commit f2e6553c2528c2afe048366821725eb3ca26e044
Author: Corinna Vinschen 
Date:   Fri Mar 10 20:16:48 2017 +0100

Drop redundant brackets in call to _reclaim_reent

Signed-off-by: Corinna Vinschen 

Diff:
---
 winsup/cygwin/thread.cc | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/winsup/cygwin/thread.cc b/winsup/cygwin/thread.cc
index 8cae82c..5076014 100644
--- a/winsup/cygwin/thread.cc
+++ b/winsup/cygwin/thread.cc
@@ -564,7 +564,7 @@ pthread::exit (void *value_ptr)
 
   if (_my_tls.local_clib.__sdidinit < 0)
 _my_tls.local_clib.__sdidinit = 0;
-  (_reclaim_reent) (_REENT);
+  _reclaim_reent (_REENT);
 
   if (InterlockedDecrement (_INTERFACE->threadcount) == 0)
 ::exit (0);

Re: Strange errors running gcc tests on Cygwin

[Achim Gratz]

Brian Inglis writes:
> Ensure that all Cygwin dlls including anything you build are included 
> in every rebase, and do an incremental rebase after every build.

Don't do this, it's not what incremental rebase is for.  I've
specifically implemented the "ephemeral" option to rebase to temporarily
deal with DLL in staging directories without polluting the global rebase
map.  The rebase map is still used if you specify that in order to work
around the address space used by the installation, but the newl rebased
libraries don't get recorded there.  Since that rebase is throw-away you
have to specify all the ephemeral DLL that can potentially collide in
each invocation of rebase.  That's still easier than doing a full rebase
once you're done building.


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

Waldorf MIDI Implementation & additional documentation:
http://Synth.Stromeko.net/Downloads.html#WaldorfDocs

--
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: Providing/Packaging a Postinstalled SUSV4 Doc only Package a la Debian

[David Stacey]

On 06/03/17 20:42, Brian Inglis wrote:

Debian provides a SUSV4 package which downloads the tar.bz2 and installs
the HTML tree from:

	http://pubs.opengroup.org/onlinepubs/9699919799/download/  


in the postinstall script, as they believe that complies with the terms
permitting individual download stated and linked at:

http://pubs.opengroup.org/onlinepubs/terms.htm

http://www.opengroup.org/legal

Is there any interest in such a package in Cygwin, and is this approach
acceptable?


Given that no-one else has replied:

Point (2) of the T linked above state that you are required to supply 
a name and e-mail address for each publication requested. You're not 
doing that (and neither should you without user consent), and so for me 
it has to be an automatic 'No' for not complying with the T IANAL.


Otherwise, I am nervous about setting a precedent for a package that 
could give different contents each time it is installed (yes, Microsoft, 
I'm looking at you too). And there are plenty of corner cases where this 
wouldn't work: offline installs, web proxies, or if the account 
performing the Cygwin install (e.g. Administrator) was blocked from 
accessing the web (on security grounds).


My thoughts aren't all negative though - there's clearly benefit in what 
you're trying to achieve.


Dave.

NTFS permissons bug?

[Don Beusee]

I'm having a problem with openssh on cygwin.  When I'm logged into 
windows, things are fine, even in a cygwin64 window:


dbeusee2@lan /e
$ cd ppscvsroot/

dbeusee2@lan /e/ppscvsroot
$ id
uid=1049863(dbeusee2) gid=1049089(Domain Users) groups=1049089(Domain 
Users),545(Users),4(INTERACTIVE),66049(CONSOLE LOGON),11(Authenticated 
Users),15(This 
Organization),66048(LOCAL),1050040(vpn-demo),1050138(CVS-PPS 
users),1049743(PPUser),1050137(CVS Users),1049741(Sharepoint 
AllUsers),401408(Medium Mandatory Level)


dbeusee2@lan /e/ppscvsroot
$ getfacl /e/ppscvsroot/
# file: /e/ppscvsroot/
# owner: Administrators
# group: Domain Users <- where is this coming from?  I have 
removed this from the permissions!  Is this cached somewhere?

user::rwx
group::---
group:SYSTEM:rwx
group:CVS-PPS users:rwx
mask:rwx
other:---
default:user::rwx
default:group::---
default:group:SYSTEM:rwx
default:group:CVS-PPS users:rwx
default:mask:rwx
default:other:---


dbeusee2@lan /e/ppscvsroot
$ ls -ld /e/ppscvsroot/
drwxrwx---+ 1 Administrators Domain Users 0 Mar  9 19:02 /e/ppscvsroot/

dbeusee2@lan /e/ppscvsroot
$


But when I ssh into it, things are not fine:

dbeusee@pp165 ~/.ssh
$ ssh dbeusee2@lan
Last login: Thu Mar  9 20:30:05 2017 from 192.168.104.74

dbeusee2@lan ~
$ id
uid=1049863(dbeusee2) gid=1049089(Domain Users) groups=1049089(Domain 
Users),11(Authenticated Users),66048(LOCAL),66049(CONSOLE 
LOGON),4(INTERACTIVE),15(This 
Organization),545(Users),1050040(vpn-demo),1049743(PPUser),1050137(CVS 
Users),1049741(Sharepoint AllUsers),401408(Medium Mandatory Level)


dbeusee2@lan ~
$ cd /e/ppscvsroot/
-bash: cd: /e/ppscvsroot/: Permission denied

dbeusee2@lan ~
$ ls -ld /e/ppscvsroot/
drwxr-x--- 1 Unknown+User Unknown+Group 0 Mar  9 19:02 /e/ppscvsroot/

dbeusee2@lan ~
$

I noticed in the "id" output in the problem ssh session, this group is 
missing: "1050138(CVS-PPS users)".  Could this be the reason?  Is sshd 
not doing group recursion?  The dbeusee2 username is a member of CVS 
Users, which has access to more CVS repositories than CVS-PPS Users.


And what's up with the Unknown+User and Unknown+Group in the ssh 
session's ls command output?


This system (lan) is running WS 2016 STD.  CVS Users group is a member 
of CVS-PPS group in AD (WS Enterprise 2003 R2).  The ppscvsroot folder 
is given access to CVS-PPS Users group. Domain Users used to be granted 
to ppscvsroot, but I removed that so that CVS-PPS Users would control 
the access.  Why am I not able to access the folder from the ssh session?


How do I solve this problem?

Version of OpenSSH (from cygwin) is:

dbeusee2@lan ~
$ ssh -V
OpenSSH_7.4p1, OpenSSL 1.0.2k  26 Jan 2017

Version of cygwin:

dbeusee2@lan ~
$ uname -a
CYGWIN_NT-10.0 lan 2.7.0(0.306/5/3) 2017-02-12 13:18 x86_64 Cygwin

Please advise.

-Don




--
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: Treating Junctions consistently, as "normal dirs" as w/linux "bind"-type mount

[Andrey Repin]

Greetings, L A Walsh!

> Andrey Repin wrote:
>> I would argue against all junctions being treated blindly.
>> The difference with bind mounts in Linux is that in Linux 
>> you don't have the
>> information available within the filesystem itself, and have 
>> no other option,
>> than to treat them as regular directories.
>> Only direct volume junctions cause an issue, and this is what 
>> should be fixed,
>> if possible, not sidetracked with questionable workarounds.
> 
> Could you describe the benefits of your proposed solution?

> You do know that MS originally called junctions "mountpoints",
> right?  So why would cygwin treating them as such be a "questionable 
> workaround"?

How they are called, and how they behave is a two different questions.

> How would you want to treat them?

Easy way: As symlinks, just like now, unless it's a volume mount point that
can't be normalized to a disk letter.

Preferred way: Fix volume mounts accessibility
 \\?\{UUID} -> /dev/disk/by-uuid/UUID


-- 
With best regards,
Andrey Repin
Friday, March 10, 2017 16:10:57

Sorry for my terrible english...


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

[ANNOUNCEMENT] Updated: xorg-server-1.19.2-1

[Jon Turney]

The following packages have been updated in the Cygwin distribution:

*** xorg-server-*1.19.2-1

These packages contain XWin and the other X.Org X11 servers.

There are no cygwin-specific changes in addition to the upstream fixes 
[1] since 1.19.1-1.


[1] https://lists.x.org/archives/xorg-announce/2017-March/thread.html

x86:
d1fe68ffdd06de51d4c0cca405be3b873cb2b7a5aabea5a5e721bb9400e67645f475ed9be099fd0409d9244855cc7c382c1a41785b8443696ee5c8d750536229 
*xorg-server-1.19.2-1-src.tar.xz
5879fddd6613dda39997a620cdfee9975bf1102accf80851e36e18c27d33c708ac6371455aad89facf94ae2b4e83e780af3698e108caf1880454f353c0a81b6f 
*xorg-server-1.19.2-1.tar.xz
5c9c6f37b7b90b030a02662d415be98787d30d3af523a892d1fa18fda7ecc5c808b9fa26ce19174b4077020180e1e97bbb0413f71ab3c40c721077a888ec5c7a 
*xorg-server-common-1.19.2-1.tar.xz
8ec3750107eaa230491623699c96dd1583d1e7864b9474bc519e87a95dc3a331da3eb952cb4ab9700d6c6bb0652bd1ddabb85abc40645521240f9e3dc8f0c88f 
*xorg-server-debuginfo-1.19.2-1.tar.xz
f1f1d850a0a08051d779a52dea68cb40791fd85d4d491177cb2f8d68ecd39456d779d644779d81dd911d56e36cd144a245cf9bd75e076efaf26ca271debdeb27 
*xorg-server-devel-1.19.2-1.tar.xz
2b12498dc50dfb937521e63ecdb34ff134b1c1a9431e3bbbc00657c0697c3b1f12027038f77729264b16633db58c79dec15e6ad2b6adb18583804e1d3a9e65ed 
*xorg-server-dmx-1.19.2-1.tar.xz
48c7fb762bfa83aab1ec800945a4a41150314a94eb59b9e9f0420beb0e7e4592d1bd7d8986b6af1a12c68edac4fc6e8b439cbd1451999b08cb69bf7fc56e32f7 
*xorg-server-extra-1.19.2-1.tar.xz
76bce46172b2cc7ab4affdd0739dc6fa946e8de2146f8552840da26df9ebcb3eda61633560660931141f200521d83fa581ff65332d7e7cfbbb57e9603ebebd19 
*xwinclip-1.19.2-1.tar.xz


x86_64:
7ed227aa5fc0eb430f970da966239ef72f038cf9da4f33076bf505c0ed9c1edc106310e2ed851df798fe04efc51b97930d77554891e438752c6fa4468c4e898a 
*xorg-server-1.19.2-1-src.tar.xz
e2642bc99e46d258c49ca50d7e6957166f3cb2ca4dc78b2cdd66ff47c4a0a67a399b752d8143811dd29846e38f305bd34b86fc4105db2b620c7a3da30cf47197 
*xorg-server-1.19.2-1.tar.xz
0165961c20b749485dc5f4a128e537a9b2bbfdfd98ee21f3615d17ebcd3aab5e087142b9d6b1ff24c1e5d0b421deb365dee61398f45c1a5aed2d59407a9fed4b 
*xorg-server-common-1.19.2-1.tar.xz
46dcda726b723c9a232d5098e55f657e4c559a6f8c6ce3efa62344ea3b3af64f336488951de059ff4f6f368817983e093cff3aebe5d69edaf7e2f49dea110a79 
*xorg-server-debuginfo-1.19.2-1.tar.xz
fab69f0612b132c5009b177f6199be413c576697ccfccdc36b0aae302a66bddc5acd375024a83ace291bf49926c366bc724b9c9f5d0edf02c11c89f489819653 
*xorg-server-devel-1.19.2-1.tar.xz
096bd4b17b240af0c09019f4c6bc5753a7c6ec5efa800f9c5dc76147ae910df5c64ed2946c4b6e0cf639fefe14247112581f1a682574c46531498ab192fcd3f2 
*xorg-server-dmx-1.19.2-1.tar.xz
391abeff950b358ab18f22aba9b7fc9bdd18dda1ee40969965d7c619efcd73ef4a0031b40eceeaf161d58c56ce174f1b0be218b13b5228b0c5ff947327a05b2b 
*xorg-server-extra-1.19.2-1.tar.xz
97a3688395995c7f7b5d10bbe782b47eef39af8e2add82c1d1aa0180c0b583150804000e4548de096d32fcf1f5f2ecb3eb8f842a1c2972532ae0927849901793 
*xwinclip-1.19.2-1.tar.xz


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

[PATCH] forkables: hardlink without WRITE_ATTRIBUTES first

[Michael Haubenwallner]

When the current process has renamed (to bin) a readonly dll, we get
STATUS_TRANSACTION_NOT_ACTIVE for unknown reason when subsequently
creating the forkable hardlink. A workaround is to open the original
file with FILE_WRITE_ATTRIBUTES access, but that fails with permission
denied for users not owning the original file.

* forkable.cc (dll::create_forkable): Retry hardlink creation using the
original file's handle opened with FILE_WRITE_ATTRIBUTES access when the
first attempt fails with STATUS_TRANSACTION_NOT_ACTIVE.
---
 winsup/cygwin/forkable.cc | 72 +++
 1 file changed, 48 insertions(+), 24 deletions(-)

diff --git a/winsup/cygwin/forkable.cc b/winsup/cygwin/forkable.cc
index 2cb5e73..ec51ebf 100644
--- a/winsup/cygwin/forkable.cc
+++ b/winsup/cygwin/forkable.cc
@@ -423,7 +423,14 @@ dll::nominate_forkable (PCWCHAR dirx_name)
 }
 
 /* Create the nominated hardlink for one indivitual dll,
-   inside another subdirectory when dynamically loaded. */
+   inside another subdirectory when dynamically loaded.
+
+   We've not found a performant way yet to protect fork against
+   updates to main executables and/or dlls that do not reside on
+   the same NTFS filesystem as the /var/run/cygfork/
+   directory.  But as long as the main executable can be hardlinked,
+   dll redirection works for any other hardlink-able dll, while
+   non-hardlink-able dlls are used from their original location. */
 bool
 dll::create_forkable ()
 {
@@ -465,14 +472,6 @@ dll::create_forkable ()
   if (devhandle == INVALID_HANDLE_VALUE)
 return false; /* impossible */
 
-  HANDLE fh = dll_list::ntopenfile ((PCWCHAR), NULL,
-   FILE_OPEN_BY_FILE_ID,
-   FILE_WRITE_ATTRIBUTES,
-   devhandle);
-  NtClose (devhandle);
-  if (fh == INVALID_HANDLE_VALUE)
-return false; /* impossible */
-
   int ntlen = wcslen (ntname);
   int bufsize = sizeof (FILE_LINK_INFORMATION) + ntlen * sizeof (*ntname);
   PFILE_LINK_INFORMATION pfli = (PFILE_LINK_INFORMATION) alloca (bufsize);
@@ -483,22 +482,47 @@ dll::create_forkable ()
   pfli->ReplaceIfExists = FALSE; /* allow concurrency */
   pfli->RootDirectory = NULL;
 
-  IO_STATUS_BLOCK iosb;
-  NTSTATUS status = NtSetInformationFile (fh, , pfli, bufsize,
- FileLinkInformation);
-  NtClose (fh);
-  debug_printf ("%y = NtSetInformationFile (%p, FileLink %W, iosb.Status %y)",
-   status, fh, pfli->FileName, iosb.Status);
-  if (NT_SUCCESS (status) || status == STATUS_OBJECT_NAME_COLLISION)
-/* We've not found a performant way yet to protect fork against updates
-   to main executables and/or dlls that do not reside on the same NTFS
-   filesystem as the /var/run/cygfork/ directory.
-   But as long as the main executable can be hardlinked, dll redirection
-   works for any other hardlink-able dll, while non-hardlink-able dlls
-   are used from their original location. */
-return true;
+  /* When we get STATUS_TRANSACTION_NOT_ACTIVE from hardlink creation,
+ the current process has renamed the file while it had the readonly
+ attribute.  The rename() function uses a transaction for combined
+ writeable+rename action if possible to provide atomicity.
+ Although the transaction is closed afterwards, creating a hardlink
+ for this file requires the FILE_WRITE_ATTRIBUTES access, for unknown
+ reason.  On the other hand, always requesting FILE_WRITE_ATTRIBUTES
+ would fail for users that do not own the original file. */
+  bool ret = false;
+  int access = 0; /* first attempt */
+  while (true)
+{
+  HANDLE fh = dll_list::ntopenfile ((PCWCHAR), NULL,
+   FILE_OPEN_BY_FILE_ID,
+   access,
+   devhandle);
+  if (fh == INVALID_HANDLE_VALUE)
+   break; /* impossible */
+
+  IO_STATUS_BLOCK iosb;
+  NTSTATUS status = NtSetInformationFile (fh, , pfli, bufsize,
+ FileLinkInformation);
+  NtClose (fh);
+  debug_printf ("%y = NtSetInformationFile (%p, FileLink %W, iosb.Status 
%y)",
+   status, fh, pfli->FileName, iosb.Status);
+  if (NT_SUCCESS (status) || status == STATUS_OBJECT_NAME_COLLISION)
+   {
+ ret = true;
+ break;
+   }
+
+  if (status != STATUS_TRANSACTION_NOT_ACTIVE ||
+ access == FILE_WRITE_ATTRIBUTES)
+   break;
+
+  access = FILE_WRITE_ATTRIBUTES; /* second attempt */
+}
+
+  NtClose (devhandle);
 
-  return false;
+  return ret;
 }
 
 /* return the number of characters necessary to store one forkable name */
-- 
2.10.2