Václav Haisman | 1 Feb 07:41 2016
Picon
Gravatar

pthread_barrier_* API implementation

Hi.

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

--

-- 
VH

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

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

Cheers.

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
Picon

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

Note : 0xC00000BE = STATUS_BAD_NETWORK_PATH

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

David Stacey | 20 Oct 22:11 2015
Picon

Coverity Scan Static Analysis

I've upgraded our Coverity Scan analysis to use Coverity version 
7.7.0.4. I've run this over the most recent snapshot code, and three 
defects were eliminated. I assume these were false positives that were 
reported by Coverity 7.6.0 but fixed in the later version. No new 
defects were detected.

The Coverity Scan analysis is performed on Cygwin snapshots as and when 
they are created. We haven't had a new snapshot for a while, and hence 
it's been over a month since Coverity was run previously.

Dave.

Basin Ilya | 1 Oct 11:52 2015
Picon

improve cygwin_attach_handle_to_fd()

Hi All.
There's undocumented function cygwin_attach_handle_to_fd() , which is
similar to Visual C _open_osfhandle() for wrapping Windows file handles.

I wanted to wrap a handle returned by CreateNamedPipe() using a custom
tool running in background and then dup the fd to parent shell using
exec 4</proc/$!/fd/4

I knew Cygwin internally used CreateNamedPipe() instead of CreatePipe()
and hoped the idea would work. Unfortunately it didn't, mainly because
cygwin_attach_handle_to_fd() calls some other windows functions on the
handle, which is fine for normal files, but makes a connected pipe unusable.

Also for stealing a pipe handle via procfs, the fd should have a special
name like "pipe:[652]". You cannot freely choose the name with
cygwin_attach_handle_to_fd()

Do you think it is possible to add another function for wrapping native
pipes and sockets? It could be less destructive for a hanlde, if it took
all the needed info from its parameters instead of querying the hanlde.

Yaakov Selkowitz | 1 Sep 23:41 2015
Picon
Gravatar

[PATCH] Allow direct access to dlmalloc

This allows programs to override malloc/free/etc. while still being able
to access the internally provided implementation.

* common.din (__libc_calloc): Export.
(__libc_free): Export.
(__libc_mallinfo): Export.
(__libc_malloc): Export.
(__libc_mallopt): Export.
(__libc_memalign): Export.
(__libc_realloc): Export.
(__libc_valloc): Export.
* malloc_wrapper.cc (__libc_free, free): Split out builtin dlmalloc
implementation into separate function.
(__libc_malloc, malloc): Ditto.
(__libc_realloc, realloc): Ditto.
(__libc_calloc, calloc): Ditto.
(__libc_memalign, posix_memalign, memalign): Ditto.
(__libc_valloc, valloc): Ditto.
(__libc_mallopt, mallopt): Ditto.
(__libc_mallinfo, mallinfo): Ditto.
---
This came to my attention due to:

https://git.gnome.org/browse/gdk-pixbuf/commit/?id=b07c3bf

Although this will likely be changed due to it being unable to link
on anything not using glibc.

The one question I have about this patch is that I see in a couple other
places that malloc-overriding code tries to override the __libc_* variants
(Continue reading)

Jon TURNEY | 24 Aug 16:20 2015
Picon
Gravatar

Investigating a fork failure


I'm not very happy with the assumption that this is SEP, so I did a bit 
more investigation into the problem in [1]

Installing "Lavasoft Ad-Aware Web Companion" into a W7 x86_64 VM, I'm 
able to reproduce that problem.

Running 'XWin -multiwindow' under WinDbg, with "Debug child processes 
also" enabled, a 2nd chance exception occurs in bash, with the following 
call stack:

>  # Child-SP          RetAddr           Call Site
> 00 00000000`0022e2e0 00000000`7755f37a ntdll!KiUserCallbackDispatcher+0x1b
> 01 00000000`0022e338 00000000`7755f3af USER32!NtUserRegisterWindowMessage+0xa
> 02 00000000`0022e340 000007fe`fe2f80f2 USER32!RegisterWindowMessageW+0x2b
> 03 00000000`0022e390 000007fe`fe2f8014 OLEAUT32!_RegisterClipFormat+0xc2
> 04 00000000`0022e470 000007fe`fe2f33c1 OLEAUT32!_typesDllMain+0x4c
> 05 00000000`0022e4a0 000007fe`fe2f3356 OLEAUT32!DllMain+0x21
> 06 00000000`0022e4d0 00000000`7768b108 OLEAUT32!CRT_INIT+0x2af
> 07 00000000`0022e630 00000000`7767787a ntdll!LdrpRunInitializeRoutines+0x1fe
> 08 00000000`0022e800 00000000`77677b5e ntdll!LdrpLoadDll+0x231
> 09 00000000`0022ea10 000007fe`fd439059 ntdll!LdrLoadDll+0x9a
> 0a 00000000`0022ea80 000007fe`ff917d66 KERNELBASE!LoadLibraryExW+0x22e
> 0b 00000000`0022eaf0 000007fe`ff915d22 ws2_32!DPROVIDER::Initialize+0x156
> 0c 00000000`0022f090 000007fe`ff933a90 ws2_32!DCATALOG::LoadProvider+0x7e
> 0d 00000000`0022f0c0 000007fe`ff920b9b ws2_32!DCATALOG::GetCountedCatalogItemFromCatalogEntryId+0x70
> 0e 00000000`0022f100 00000001`800ab085 ws2_32!_chkstk+0x362a
> 0f 00000000`0022f1a0 00000001`8006d8b7 cygwin1!feinitialise+0x33f95
> 10 00000000`0022f1f0 00000001`800469d0 cygwin1!dlfork+0x3ac7
> 11 00000000`0022f250 00000001`8004897c cygwin1!setprogname+0x3ed0
(Continue reading)

David Stacey | 29 Apr 19:58 2015
Picon

Coverity: Update to version 7.6.0

If there are no objections, I'd like to update our weekly Coverity scan 
to use Coverity Analysis 7.6.0 (presently we're using 7.5.0). There 
should be fewer false positives this week, but there might be some new 
coding defects picked up also.

Dave.

Bryan Berns | 17 Apr 20:11 2015
Picon

Potential Enhancement Of 'noacl'?

Wasn't sure which mailing list I should throw this on so I apologize
if this is the wrong one -- just let me know for future purposes.

At least for my internal use, I plan to create a patch that will allow
me to conditionally force a permission set for a particular mount
point -- like an enhanced "noacl".  I was thinking about adding an
option after noacl[=XXX] where XXX would force XXX as the returned
permissions for any file on that mount point.

Why would someone want to do this crazy thing?  In short, I continue
to struggle with the current Cygwin permissions handling for certain
drives where programs do sanity checks on group readability (e.g.,
ssh).  Our drives have ACEs for various admin groups.  Regardless of
various philosophical viewpoints on file system administration, that's
how it is for us and it's not going to change.  I believe a select
group of others might be in this same boat.

The only other alternative that would work for us to would be read a
custom list of SIDS to ignore in group permission calculations but I
already know Corinna is not a fan of that.

Would this (the noacl thing) be something that we'd be potentially
willing to incorporate into the codebase?  If I know ahead of time,
I'll make sure I address some other artifacts (user guide
documentation, etc).

Thanks,

Bryan

(Continue reading)


Gmane