[PATCH 1/1] cherry-pick fix for pkg-config
This PR removes a recently added -R/usr/lib from the linker flags, which is
incompatible with gcc:
$ cc $(pkg-config --libs libbrotlidec)
cc: error: unrecognized command-line option ‘-R’
---
brotli.cygport | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/brotli.cygport b/brotli.cygport
index dbf43b7..91deb5c 100644
--- a/brotli.cygport
+++ b/brotli.cygport
@@ -4,7 +4,7 @@ inherit cmake python-wheel
NAME="brotli"
VERSION=1.0.9
-RELEASE=1
+RELEASE=2
CATEGORY="Libs"
SUMMARY="Brotli compression format library"
DESCRIPTION="Brotli is a generic-purpose lossless compression algorithm that
@@ -14,6 +14,7 @@ comparable to the best currently available general-purpose
compression methods.
It is similar in speed with deflate but offers more dense compression."
HOMEPAGE="https://github.com/google/brotli;
SRC_URI="${HOMEPAGE}/archive/v${VERSION}/brotli-v${VERSION}.tar.gz"
+PATCH_URI="${HOMEPAGE}/commit/092446fafb4bfb81738853b7c7f76b293cd92a80.patch"
BUILD_REQUIRES="\
cmake\
--
2.31.1
--
Problem reports: https://cygwin.com/problems.html
FAQ: https://cygwin.com/faq/
Documentation:https://cygwin.com/docs.html
Unsubscribe info: https://cygwin.com/ml/#unsubscribe-simple
[PATCH 0/1] libbrotli has broken pkg-config
I'm a little lost on the exact process for sending patches for packages, so excuse me if I'm in the wrong place. I found this problem when trying to build something that depends on libbrotli. This patch pulls the fix from this PR: https://github.com/google/brotli/pull/838 David McFarland (1): cherry-pick fix for pkg-config brotli.cygport | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) -- 2.31.1 -- Problem reports: https://cygwin.com/problems.html FAQ: https://cygwin.com/faq/ Documentation:https://cygwin.com/docs.html Unsubscribe info: https://cygwin.com/ml/#unsubscribe-simple
[PATCH] Cygwin: create install dir for libs
This fixes a race in parallel installs. --- winsup/cygwin/Makefile.in | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/winsup/cygwin/Makefile.in b/winsup/cygwin/Makefile.in index fac81759e..ea0243033 100644 --- a/winsup/cygwin/Makefile.in +++ b/winsup/cygwin/Makefile.in @@ -600,7 +600,7 @@ install: install-libs install-headers install-man install-ldif install_target \ uninstall: uninstall-libs uninstall-headers uninstall-man install-libs: $(TARGET_LIBS) - @$(MKDIRP) $(DESTDIR)$(bindir) + @$(MKDIRP) $(DESTDIR)$(bindir) $(DESTDIR)$(tooldir)/lib $(INSTALL_PROGRAM) $(TEST_DLL_NAME) $(DESTDIR)$(bindir)/$(DLL_NAME); \ for i in $^; do \ $(INSTALL_DATA) $$i $(DESTDIR)$(tooldir)/lib/`basename $$i` ; \ -- 2.28.0
Re: unhandled C++ exceptions not propagating
Takashi Yano writes:
> On Sat, 15 Aug 2020 20:38:01 -0300
> David McFarland via Cygwin wrote:
>>
>> I was just debugging a c++ app (b2 build system from boost), and noticed
>> that it would appear to exit unexpectedly without an error. This turned
>> out to be when an unhandled C++ exception was thrown.
>>
>> On a fresh install of cygwin with gcc-g++, this program will throw an
>> exception from the std::string constructor:
>>
>> c++ -x c++ - <> #include
>> int main() { std::string str(nullptr); return 0; }
>> END
>>
>> When it's executed from the shell it returns zero, but execution stops
>> at the exception.
>>
>> $ ./a; echo $?
>> 0
>>
>> When executed under gdb, the exception is caught, and the process exits
>> non-zero when continued:
>>
>> (gdb) r
>> Starting program: /home/corngood/a
>> [New Thread 4300.0x1390]
>> [New Thread 4300.0x1d24]
>> [New Thread 4300.0x1d48]
>> [New Thread 4300.0x80c]
>> gdb: unknown target exception 0x20474343 at 0x7ff8d2cfa799
>> Thread 1 "a" received signal ?, Unknown signal.
>> 0x7ff8d2cfa799 in RaiseException () from
>> /cygdrive/c/WINDOWS/System32/KERNELBASE.dll
>> (gdb) c
>> Continuing.
>> [Thread 4300.0x1d24 exited with code 541541187]
>> [Thread 4300.0x1870 exited with code 541541187]
>> [Thread 4300.0x1d48 exited with code 541541187]
>> [Thread 4300.0x1390 exited with code 541541187]
>> [Inferior 1 (process 4300) exited with code 04021641503]
>> (gdb)
>>
>> When executed under strace, it exits with an error as expected:
>>
>> $ strace -o /dev/null a; echo $?
>> 67
>>
>> That's as far as I've investigated so far.
>
> Is this the same issue with
> https://cygwin.com/pipermail/cygwin/2019-October/242795.html ?
>
> As far as I tested, this does not occur in 32-bit cygwin.
Yeah, it seems to be. Thanks for tracking that down.
I tried using ProcessMonitor, and when I run the test program from a
shell (where it appears to return 0) I get:
a.exe 7096Process ExitSUCCESS Exit Status: 541541187, User
Time: 0.000 seconds, Kernel Time: 0.000 seconds, Private Bytes:
4,661,248, Peak Private Bytes: 4,661,248, Working Set: 4,255,744, Peak Working
Set: 4,259,840
So the win32 process does appear to be exiting non-zero.
Did you find out anything else when you investigated it? My next step
was going to be digging into why it behaves differently under strace.
--
Problem reports: https://cygwin.com/problems.html
FAQ: https://cygwin.com/faq/
Documentation:https://cygwin.com/docs.html
Unsubscribe info: https://cygwin.com/ml/#unsubscribe-simple
unhandled C++ exceptions not propagating
I was just debugging a c++ app (b2 build system from boost), and noticed
that it would appear to exit unexpectedly without an error. This turned
out to be when an unhandled C++ exception was thrown.
On a fresh install of cygwin with gcc-g++, this program will throw an
exception from the std::string constructor:
c++ -x c++ - <
int main() { std::string str(nullptr); return 0; }
END
When it's executed from the shell it returns zero, but execution stops
at the exception.
$ ./a; echo $?
0
When executed under gdb, the exception is caught, and the process exits
non-zero when continued:
(gdb) r
Starting program: /home/corngood/a
[New Thread 4300.0x1390]
[New Thread 4300.0x1d24]
[New Thread 4300.0x1d48]
[New Thread 4300.0x80c]
gdb: unknown target exception 0x20474343 at 0x7ff8d2cfa799
Thread 1 "a" received signal ?, Unknown signal.
0x7ff8d2cfa799 in RaiseException () from
/cygdrive/c/WINDOWS/System32/KERNELBASE.dll
(gdb) c
Continuing.
[Thread 4300.0x1d24 exited with code 541541187]
[Thread 4300.0x1870 exited with code 541541187]
[Thread 4300.0x1d48 exited with code 541541187]
[Thread 4300.0x1390 exited with code 541541187]
[Inferior 1 (process 4300) exited with code 04021641503]
(gdb)
When executed under strace, it exits with an error as expected:
$ strace -o /dev/null a; echo $?
67
That's as far as I've investigated so far.
--
Problem reports: https://cygwin.com/problems.html
FAQ: https://cygwin.com/faq/
Documentation:https://cygwin.com/docs.html
Unsubscribe info: https://cygwin.com/ml/#unsubscribe-simple
[PATCH 1/1] Cygwin: Fix cygheap corruption caused by cloned atomic buffer
The fhandler_base_overlapped::copyto clears atomic_write_buf on the
clone, but none of the derived classes were doing this. This allowed
the destructor to double-free the buffer and corrupt cygheap.
Clear atomic_write_buf in copyto of all derived classes.
---
winsup/cygwin/fhandler.h | 2 ++
1 file changed, 2 insertions(+)
diff --git a/winsup/cygwin/fhandler.h b/winsup/cygwin/fhandler.h
index 2cc99d713..9e63867ab 100644
--- a/winsup/cygwin/fhandler.h
+++ b/winsup/cygwin/fhandler.h
@@ -1216,6 +1216,7 @@ public:
{
x->pc.free_strings ();
*reinterpret_cast (x) = *this;
+reinterpret_cast (x)->atomic_write_buf = NULL;
x->reset (this);
}
@@ -1256,6 +1257,7 @@ public:
{
x->pc.free_strings ();
*reinterpret_cast (x) = *this;
+reinterpret_cast (x)->atomic_write_buf = NULL;
x->reset (this);
}
--
2.19.1
[PATCH 0/1] Fix deadlocks related to child processes
For a long time I've been struggling with intermittent deadlocks and segfaults in emacs, seemingly related to invoking child processes. I recently found a reliable way to reproduce one such deadlock: - install clean cygwin with: emacs-w32, clang - install flycheck from elpa - grab some non trivial C header e.g.: $ cp /usr/include/stdio.h test.h - $ emacs -q test.h - start flycheck: (progn (package-initialize) (require 'flycheck) (flycheck-mode)) - add a character to the start of the first line - wait for flygheck to complete - repeat the last two steps until a deadlock occurs Breaking in gdb showed the main thread in `cygheap_protect.acquire ()`, from either _cfree or _cmalloc. The thread holding the mutex was always "flasio", and it would either be continually segfaulting or looping in _cfree. I added some debug prints to cygheap and determined that it flasio was double-freeing an atomic_write_buf. I added some more prints and found that it was two different fhandler objects freeing the same buffer. I then found that `fhandler_base_overlapped::copyto` would clear the buffer pointer after the copy, but none of the derived classes (pipe, fifo) did. Attached is a patch which clears the buffer pointers when copying pipes and fifos. It would probably be safer to move the buffer clear to a `operator=`, but I wanted to keep the patch as simple as possible and avoid refactoring. David McFarland (1): Cygwin: Fix cygheap corruption caused by cloned atomic buffer winsup/cygwin/fhandler.h | 2 ++ 1 file changed, 2 insertions(+) -- 2.19.1
