Michael Haubenwallner | 1 Jun 08:40 2016

About the dll search algorithm of dlopen


two issues with dlopen here (I'm about to prepare patches):

*) The algorithm to combine dll file name variants with the search path
   entries needs to be reordered, as in:
   - for each dll file name variant:
   -   for each search path:
   + for each search path entry:
   +   for each dll file name variant:
         check if useable

*) The directory of the current main executable should be searched
   after LD_LIBRARY_PATH and before /usr/bin:/usr/lib.
   And PATH should be searched before /usr/bin:/usr/lib as well.

   For consistency, IMO, when any searched path ends in either
   x/bin or x/lib, we should search x/bin:x/lib.



Michael Haubenwallner | 13 May 12:46 2016

About <sys/select.h> and <sys/time.h>, without gnulib


independent of gnulib, I don't believe this include order should break:

   $ cat sys-time-h.c
   #include <sys/select.h>
   #include <sys/time.h>

   $ gcc -c sys-time-h.c
   In file included from /usr/include/time.h:12:0,
                    from /usr/include/sys/time.h:268,
                    from sys-time-h.c:2:
   /usr/include/sys/reent.h:276:3: error: expected specifier-qualifier-list before ‘_fpos64_t’
      _fpos64_t _EXFNPTR(_seek64, (struct _reent *, _PTR, _fpos64_t, int));

This is with 64-bit cygwin-2.5.1 and gcc-5.3.0.

It does help to reverse their order, or include <sys/types.h> before,
but I've failed to find something like that to be required by the specs...


Michael Haubenwallner | 4 May 15:51 2016

Cygwin headers changed? (breaking gettext- build)


as I do have troubles compiling my own gettext package, I've realized
that even building current gettext- package is broken,
somewhere within gnulib sources - build log attached.

Commands used to build:
$ tar xf gettext-
$ cd gettext-
$ cygport -8 gettext.cygport prep compile

Cygwin version used is 2.5.1-1.

Seems like something has changed in the Cygwin headers, which either has
unexpected side effects, or gnulib should stop working around something?

Michael Haubenwallner | 12 Apr 10:51 2016

About bidirectional named pipes (FIFO)


I'm encountering problems with some multi-processing bash script
that boils down to:

$ bash -c '
    rm -f /tmp/testpipe.$$
    trap "rm -f /tmp/testpipe.$$" EXIT
    mkfifo /tmp/testpipe.$$
    exec {fw}<>/tmp/testpipe.$$
    exec {fr}<>/tmp/testpipe.$$
    for x in {1..10}
         trap "echo job $x pid \$BASHPID status \$? done >& $fw" EXIT
         exit $x
      ) &
    for z in {1..10}
      read -u $fr
      echo $REPLY

Agreed, POSIX does not define behaviour for using '<>' with fifos,
but it works with AIX, *BSD, HP-UX, Interix, Linux, Solaris, ...

(Continue reading)

Mark Geisert | 8 Mar 05:09 2016

child process initialization as part of fork()

I've finally figured out why my recent profiling updates don't often work 
for the case of a profiled program fork()ing with both parent and child 
continuing on until exit without exec()ing.  There is some static data in 
libgmon.a that needs updating to be correct in the child after a fork(). 
I would like to make use of gcrt0.c's _monstartup() to determine when the 
data needs to be updated, but there's a catch.

_monstartup() is declared "__attribute__((__constructor__))" which is 
ideal for my purposes.  But investigation has revealed that during fork() 
the constructor is being run by the parent process, rather than the child 
process as one would expect.

Is this behavior required by the current fork() implementation?  Some kind 
of chicken-and-egg problem avoidance maybe?

I suspect changing gmon from a static library to a DLL and using NO_COPY 
could avoid the issue but that has a performance impact I'd like to avoid.


Mark Geisert | 16 Feb 03:23 2016

Silent relocation truncations considered harmful

This follows up from my msg re GMP-ECM failing its 'make check' on the 
main list https://cygwin.com/ml/cygwin/2016-02/msg00147.html .

There's an error that ought to be reported during dynamic linking if 
the linked-to address is too far from the relocation site.  However the 
error is not reported if __OPTIMIZE__ was #defined when building the 
Cygwin DLL.  I can't see why optimization settings should affect this,
so I suggest:

/oss/src/winsup/cygwin diff -u pseudo-reloc.cc.safe pseudo-reloc.cc
--- pseudo-reloc.cc.safe        2016-01-26 20:08:06.000000000 -0800
+++ pseudo-reloc.cc     2016-02-15 17:54:20.475963800 -0800
 <at>  <at>  -342,7 +342,7  <at>  <at> 
           __write_memory ((void *) reloc_target, &reldata, 2);
         case 32:
-#if defined (__CYGWIN__) && defined (__x86_64__) && !defined (__OPTIMIZE__)
+#if defined (__CYGWIN__) && defined (__x86_64__)
           if (reldata > (ptrdiff_t) __INT32_MAX__
               || reldata < -((ptrdiff_t) __INT32_MAX__) - 1)
             __report_error ("Invalid relocation.  Offset %p at address %p "

If the truncation is not reported here, which kills the program with a 
Cygwin runtime error, you get hard to diagnose SIGSEGVs at some later time 
when the app tries to call a function at an address relocated off in the 
weeds somewhere.


(Continue reading)

Václav Haisman | 1 Feb 07:41 2016

pthread_barrier_* API implementation


On rakudo.org ([1]) pages, I have noticed that the pthread_barrier_*
POSIX API is missing from Cygwin. I took a look at NetBSD and FreeBSD
implementations of it. It seemed to me that creating POSIX barrier on
top of POSIX mutex and POSIX conditional variable is not that hard ([2]).

Now, the question is whether this is acceptable and whether it should be
part of Newlib or directly part of Cygwin?

Second, if I should pursue that, or if anyone who knows either Newlib or
Cygwin better than I wants to mould the source into an acceptable form.
I would not mind somebody else doing it. :D

I have, in the past, contributed small patches to Cygwin and I had done
the necessary copyright assignment paper work, so copyright should not
be a problem.

[1]: http://rakudo.org/how-to-get-rakudo/#Installing-Rakudo-Star-Cygwin
[2]: https://gist.github.com/wilx/bb77de5d3f554afedd79



Mark Geisert | 29 Jan 11:20 2016

gprof profiling of multi-threaded Cygwin programs

I've got alpha-quality code running to support this and am running some 
tests to ensure I'm seeing what I ought to be seeing.  Could I get a quick 
design review to confirm I'm on the right track of implementation and 
to maybe point out odd use cases I might have missed?

I could have just submitted patches but I'd like to be more sure of my 
direction before patching.

I see three areas of implementation...
(1) Modify profil.c to have the profiling thread it creates sample all 
pthreads' pc values in addition to its current sampling of the main 
thread's.  I plan to have profil.c call a routine in cygheap.cc to get 
handles to the running pthreads that can be passed to GetThreadContext() 
back in profil.c.  (The code is cleaner than this reads.)

(2) Modify mcount.c to make mcount_private() thread-safe.  This routine is 
entered on every function call that occurs in an executable compiled with 
the '-pg' option; this to build call path diagrams.  I plan to replace the 
sets and refs of the gmonparam state variable with Interlocked* 
operations.  It would be nice to record somewhere how many misses occur; 
the code doesn't queue callers because it's being called on *every* 
profiled function call.  That happens so very frequently under profiling 
that if the state doesn't allow entry that call's info is just discarded.

(3) Modify gmon.c to allow for possibility of multiple gmon.out files due 
to fork/exec from a profiled process.  I see there is potentially usable 
code already there but it's #ifdef'd out.  Does anybody know why?

Thanks for the once-over and if submitting patches really is the way I 
should go for this review, just let me know.
(Continue reading)

Yucong Sun | 5 Dec 15:32 2015

Re: Jemalloc under CYGWIN

I'm sorry, I got distracted from this issue and hadn't make any progress.

One thing specifically I need to be able to work on this issue is some
information describing how to build/test cygwin lib (rather than using
it). I couldn't find any information on the website, (or I havn't look
deeply enough).


Michael Haubenwallner | 13 Nov 17:12 2015

Protect fork() against dll- and exe-updates.

Hi Corinna,

have reworked the hardlink-creation from scratch as discussed before,
now using /var/run/cygfork/ as the top-level hardlinks directory.

* At process start and during LoadLibrary, handles to all the loaded
  dlls (including cygwin1.dll) and the main executable are opened.

* At fork(), immediately before that CreateProcessW, all the dlls
  registered above are checked by filesystem if they still are
  identical as loaded in the current process - as long as the
  /var/run/ directory is on NTFS and the cygfork directory exists.

* If they are not identical (any more), hardlinks to these dlls are
  created in subdirectories into /var/run/cygfork/≤sid>/.

* The name of that subdirs is mangled using the /path/to.exe and the
  most recent ftLastWriteTime found in the list of loaded dlls.
  This is necessary to allow for one dll to be used by concurrent
  processes when started before and after that dll's update.

* The creation and removal of these directories and hardlinks is
  synchronized via some mutex, which's name contains the same names as
  the directories created.

* The removal is done by iterating over all the directories found in
  /var/run/cygfork/, recreating the mutex-names along these directory
  names, and removing them only if the named mutex does not exist any
  more. This ensures to clean up even in case of power-loss or similar.
(Continue reading)

Andy O'Shaughnessy | 29 Oct 12:47 2015

NFS share - NtOpenFile() failed, c00000be

I am able to mount an NFS share from Linux but when I use Cygwin I get
a stranger error:

$ mount //<server>/<share> /tmp/test1

$ ls -lrt /tmp
ls: cannot access /tmp/test1: No such file or directory
total 0
d????????? ? ? ? ?            ? test1

But when I run the following I get :

$ /usr/lib/csih/getVolInfo /tmp/test1
NtOpenFile(\??\UNC\<server>\<share>) failed, c00000be


The mount happened but not properly.
It might be linked to Windows McAfee Firewalls.
I would guess this mailing list will readily know what is wrong