emacs-auctex 13.1-1
The following packages have been uploaded to the Cygwin distribution: * emacs-auctex-13.1-1 * preview-latex-13.1-1 AUCTeX is an extensible package for writing and formatting TeX files in GNU Emacs. It supports many different TeX macro packages, including AMS-TeX, LaTeX, Texinfo, ConTeXt, and DocTeX (dtx files). AUCTeX includes preview-latex, which makes LaTeX a tightly integrated component of your editing workflow by visualizing selected source chunks (such as single formulas or graphics) directly as images in the source buffer. preview_latex is a self-contained subpackage of emacs-auctex that allows appropriately selected parts of a LaTeX document to be formatted and displayed within the Emacs editor. It also has uses that do not require Emacs. This is an update to the latest upstream major release. See the announcement at https://lists.gnu.org/archive/html/info-auctex/2022-02/msg0.html for details. Note: An alternative to installing this package is to install AUCTeX via the Emacs package manager (ELPA) instead. Simply do 'M-x list-packages ' within Emacs, mark the auctex package for installation with 'i', and hit 'x' to execute the installation procedure This alternative is in fact strongly recommended by the AUCTeX developers. One advantage is that you will receive intermediate bugfix releases between major AUCTeX releases conveniently. For example, version 13.1.1 is already available through ELPA. Ken Brown Cygwin's emacs-auctex maintainer
Re: Updating glib2 in cygwin
[Redirecting to the cygwin-apps list] On 2/28/2022 3:49 AM, Marc-André Lureau wrote: Hi Ken I am a qemu developer at Red Hat. The "official" qemu Windows build uses cygwin, and the glib version there is quite old. I saw you have made some effort to update the package (https://www.cygwin.com/git-cygwin-packages/?p=git/cygwin-packages/glib2.0.git;a=search;h=refs/heads/playground;s=Ken+Brown;st=author) What's the situation? Is there a bug tracking the issues? Hi Marc, The last discussion of this that I can recall started here: https://cygwin.com/pipermail/cygwin-apps/2020-May/040105.html What's needed is for someone to adopt all of the GNOME components and maintain them. As you'll see in the discussion I cited, I briefly considered updating only glib2 and a few others, but then I decided that I wasn't willing to take the responsibility of fixing/updating other components that broke as a result of this. So I pushed what I had done and left it there. It would be great if someone would step up and take over, but I'm not in a position to do that myself. Ken
Re: cygpath not doing anything on a fresh install
On 2/8/2022 9:37 AM, Antonio Petrelli wrote: Il giorno mar 8 feb 2022 alle ore 15:30 marco atzeri ha scritto: check if strace give some hints strace -o /tmp/strace.txt /usr/bin/cygpath --help The result is here: https://pastebin.com/n56RTAiu This looks suspicious: Process 2480 loaded C:\Program Files\SentinelOne\Sentinel Agent 21.7.4.1043\InProcessClient64.dll at 7ffb7c94 I suspect that SentinelOne is interfering with Cygwin (see https://cygwin.com/faq/faq.html#faq.using.bloda). Can you disable it or at least exclude the Cygwin directory from whatever it does? Ken -- 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
[ANNOUNCEMENT] lcms2 2.13-1
The following packages have been uploaded to the Cygwin distribution: * lcms2-2.13-1 * liblcms2_2-2.13-1 * liblcms2-devel-2.13-1 Little CMS intends to be an Open Source small-footprint color management engine, with special focus on accuracy and performance. It uses the International Color Consortium standard (ICC), which is the modern standard regarding color management. The ICC specification is widely used and is referred to in many International and other de-facto standards. This is an update to the latest upstream release. See https://littlecms.com/blog/2022/01/28/lcms2-2.13/ for a list of changes since the previous release. Ken Brown Cygwin's lcms2 maintainer -- 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
lcms2 2.13-1
The following packages have been uploaded to the Cygwin distribution: * lcms2-2.13-1 * liblcms2_2-2.13-1 * liblcms2-devel-2.13-1 Little CMS intends to be an Open Source small-footprint color management engine, with special focus on accuracy and performance. It uses the International Color Consortium standard (ICC), which is the modern standard regarding color management. The ICC specification is widely used and is referred to in many International and other de-facto standards. This is an update to the latest upstream release. See https://littlecms.com/blog/2022/01/28/lcms2-2.13/ for a list of changes since the previous release. Ken Brown Cygwin's lcms2 maintainer
Re: A change to how calm expires packages
On 1/20/2022 9:33 AM, Jon Turney wrote: texlive-collection-latexrecommended-doc: untest 20210118-2 and expire 20210118-1 Yes, please. It was just a mistake that I never untested 20210118-2. Ken
Re: how to obsolete now-removed subpackage?
On 1/20/2022 7:14 AM, Glenn Strauss wrote: lighttpd 1.4.64 removes long-deprecated packages, including mod_trigger_b4_dl (replaceable with a lua script, if needed) I am trying to build using lighttpd.cygport and after uploading package 1.4.64-1, I got errors, so I tried adding PKG_OBSOLETES="lighttpd-mod_trigger_b4_dl" to lighttpd.cygport and building lighttpd.cyport package 1.4.64-2 Am I using PKG_OBSOLETES incorrectly? Yes. The cygport manual says that PKG_OBSOLETES is "A single-line string containing a list of package(s) which this package replaces Note that the PKG_OBSOLETES name is descriptive rather than literal, where "PKG" should be substituted with the name of the binary package whose contents it describes." Is there something else I need to do to remove this subpackage? I think what you want is simply for lighttpd-mod_trigger_b4_dl to be empty, which you can achieve with lighttpd_mod_trigger_b4_dl_CONTENTS= Ken
Re: [PATCH] fhandler_pipe: add sanity limit to handle loops
On 1/13/2022 5:56 AM, Takashi Yano wrote: Ken Brown wrote: 2. You can use the ReturnLength parameter of NtQueryInformationProcess to see how big a buffer is needed. This might be more efficient than repeatedly doubling the buffer size. Even if ReturnLength is used, the first NtQueryInformationProcess() call and the second NtQueryInformationProcess() call will not be done in atomic, so retrying is still necessary. However, it may be more efficient as you mentioned. The similar is true also for NtQuerySystemInformation(). Do you still think it is better to use ReturnLength rather than doubling the buffer? I'm not sure. I only mentioned it because I saw that that's what Process Hacker did, but still in a retry loop as you said. I suspect it doesn't make a lot of difference in practice, since we call the function once and then cache the value. Do whatever you think is best. Thanks. Ken -- 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
Re: posix_spawn issues on i686
On 1/12/2022 5:41 AM, Corinna Vinschen wrote: On Jan 11 16:08, Ken Brown wrote: I don't have time to check this carefully, but it looks to me like the problem is that process_spawnattr calls setegid and seteuid instead of setegid32 and seteuid32. This causes truncation of the gid and uid. You're right. Additionally the calls to getgid and getuid have to use the internal getgid32 and getuid32 functions. I'll be glad when this 32-bit cruft can be removed. It is *very* confusing to read the code and see a function called getuid that is really only used by old applications, except when it's accidentally used internally. I introduced a 32-bit-only bug a couple years ago because of a similar confusion between fstat and fstat64. Ken -- 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
Re: posix_spawn issues on i686
On 1/11/2022 1:45 PM, Jeremy Drake via Cygwin wrote: Sorry, I am not subscribed to the list so don't have the message to reply to for threading purposes, but attached please find a C reproducer that works on x86_64 but fails on i686. The particular issue seems to be the POSIX_SPAWN_RESETIDS flag - not setting that allows i686 to succeed too. I don't have time to check this carefully, but it looks to me like the problem is that process_spawnattr calls setegid and seteuid instead of setegid32 and seteuid32. This causes truncation of the gid and uid. Ken -- 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
Re: Unable to open the clipboard
On 1/3/2022 9:34 AM, Marco Atzeri wrote: Hi Guys, I noticed, from time to time, that on recent Cygwin $ uname -svr CYGWIN_NT-10.0 3.3.3(0.341/5/3) 2021-12-03 16:35 there seems to be a "failed race (?)" using the clipboard $ putclip < Announce_geos Unable to open the clipboard Hi Marco, There was a clipboard bug that Takashi fixed in commit 69ed8ca20. I don't know if it's the same issue that you're seeing. The fix will appear in Cygwin 3.3.4, or you could try the latest snapshot. Ken -- 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
Re: [PR] cygport (update required for autoconf-2.71)
On 1/2/2022 12:22 PM, Marco Atzeri wrote: On 05.12.2021 10:34, Achim Gratz wrote: In order for cygport to work correctly when autoconf 2.71 is requested, please pull the first commit (b25cb3faa) on my to-upstream branch into upstream and release a new version. I'd appreciate if the full branch would be pulled, these are all used by me for quite some time already. ... Regards, Achim. I see that "officially" Yaakov is still the maintainer https://cygwin.com/packages/summary/cygport.html but I do not remember any commitment from him to do so. If Yaakov declines, how can we manage the ownership ? There was a discussion on IRC in which Jon Turney agreed to take over. Ken
Re: perl_base not in Base ?
On 12/30/2021 5:38 AM, Achim Gratz wrote: Am 29.12.2021 um 17:12 schrieb Jon Turney: I think this was the case, at one time. As I said before, at least info still does; not directly, though (it requires a bunch of Perl module distribution that will then pull in perl_base at least). No, info just requires a few libs. You're thinking of texinfo, but it's not in Base. Ken
Re: w3m displays blank help page
On 12/29/2021 4:44 PM, Gary Johnson wrote: So, I have a workaround for the problem, but I'd really like a proper fix, and there may be other users with this problem. w3m currently has no maintainer. Would you like to take over? Ken -- 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
Re: [PATCH] fhandler_pipe: add sanity limit to handle loops
On 12/26/2021 6:12 PM, Ken Brown wrote: There are some fixes (though not pipe-related) pending for 3.3.4, so I'll push it to the 3.3 branch after I've heard from Takashi and/or Corinna. Takashi must be unavailable also, but it's a simple enough fix that I decided to go ahead and push it. Ken
Re: perl_base not in Base ?
On 12/29/2021 3:51 AM, Achim Gratz wrote: Am 28.12.2021 um 11:57 schrieb Marco Atzeri: I had the impression it was in the Base category @ perl_base sdesc: "Perl programming language interpreter" ldesc: "Perl programming language interpreter That split was indeed made to enable making it available for Base packages, but that decision was never made I think. It makes sense to me to add it to Base. Were there any objections when that was proposed before? Or is it supposed to be pulled by another Base program ? Base packages should not pull in non-Base packages, but it appears that info currently fails that requirement. A lot of packages fail that requirement. I don't think it should be a requirement. To me, Base packages are those that we've decided should be in every Cygwin installation. If that forces other packages to be installed, so be it. Ken
Re: Can't load CSS mode in Emacs
On 12/28/2021 3:37 PM, Jim Reisert AD1C wrote: I'm using the test version of Emacs 28.0.60. I can't seem to load css-mode (Cascading Style Sheets). I get the following error in the console window: 0 [main] emacs-X11 1297 child_info_fork::abort: address space needed by 'url-history-a9b2f6e8-97761513.eln' (0xAD) is already occupied Any idea what's going on? This means that the .eln files need to be rebased. Please close all Cygwin processes and run setup-x86_64.exe so that autorebase can do its thing. Make sure that /var/lib/rebase/userpath.d/ has been created as explained in the release announcement. Ken -- 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
Re: [PATCH] fhandler_pipe: add sanity limit to handle loops
On 12/26/2021 6:23 PM, Jeremy Drake wrote: On Sun, 26 Dec 2021, Ken Brown wrote: On 12/26/2021 5:43 PM, Jeremy Drake wrote: My loops are still going after an hour. I know that ARM64 would have hit the assert before now. Well, ARM64 hung up, but didn't hit the assert, so maybe there's some *other* issue running around. Unfortunately gdb doesn't work to attach to a process there (it gets confused with the ARM64 DLLs loaded in the process). And WinDbg can't load the symbols for a cygwin dll (cv2pdb generally works pretty well for this, but it seems to be confused by the split .dbg file for msys-2.0.dll). Sounds like nothing can be done until it shows up on x86_64. Ken
Re: [PATCH] fhandler_pipe: add sanity limit to handle loops
On 12/26/2021 5:43 PM, Jeremy Drake wrote: On Sun, 26 Dec 2021, Ken Brown wrote: + /* NtQueryInformationProcess can return STATUS_SUCCESS with +invalid handle data for certain processes. See + https://github.com/processhacker/processhacker/blob/master/phlib/native.c#L5754. I would recommend using the "permalink" to the line, since future commits could change both the line number and even the comment you are referring to. https://github.com/processhacker/processhacker/blob/05f5e9fa477dcaa1709d9518170d18e1b3b8330d/phlib/native.c#L5754 Good idea, thanks. +We need to ensure that NumberOfHandles is zero in this +case to avoid a crash in the loop below. */ + phi->NumberOfHandles = 0; status = NtQueryInformationProcess (proc, ProcessHandleInformation, phi, nbytes, ); if (NT_SUCCESS (status)) Would it make sense to leave an assert (phi->NumberOfHandles <= n_handle) before the for loop too just in case something odd happens in the future? That made it a lot easier to know what was going on. Yes, I think so. My loops are still going after an hour. I know that ARM64 would have hit the assert before now. Would this also be pushed to the 3.3 branch? Or are there plans to make a 3.3.4 at some point? I saw a pipe-related hang reported to MSYS2 (that I didn't see this issue in the stack traces), but I am not sure if there are any more pipe fixes pending post 3.3.3. There are some fixes (though not pipe-related) pending for 3.3.4, so I'll push it to the 3.3 branch after I've heard from Takashi and/or Corinna. Ken
Re: [PATCH] fhandler_pipe: add sanity limit to handle loops
On 12/26/2021 4:35 PM, Jeremy Drake wrote:
On Sun, 26 Dec 2021, Ken Brown wrote:
On 12/26/2021 11:04 AM, Ken Brown wrote:
On 12/26/2021 10:09 AM, Ken Brown wrote:
1. For some processes, NtQueryInformationProcess(ProcessHandleInformation)
can return STATUS_SUCCESS with invalid handle information. See the
comment starting at line 5754, where it is shown how to detect this.
I kind of thought something like this (that NumberOfHandles was
uninitialized memory).
If I'm right, the following patch should fix the problem:
diff --git a/winsup/cygwin/fhandler_pipe.cc b/winsup/cygwin/fhandler_pipe.cc
index ba6b70f55..4cef3e4ca 100644
--- a/winsup/cygwin/fhandler_pipe.cc
+++ b/winsup/cygwin/fhandler_pipe.cc
@@ -1228,6 +1228,7 @@ fhandler_pipe::get_query_hdl_per_process (WCHAR *name,
HeapAlloc (GetProcessHeap (), 0, nbytes);
if (!phi)
goto close_proc;
+ phi->NumberOfHandles = 0;
status = NtQueryInformationProcess (proc,
ProcessHandleInformation,
phi, nbytes, );
if (NT_SUCCESS (status))
Actually, this first hunk should suffice.
Jeremy, could you try this?
Ken
I've built (leaving the assert in place too), and I've got 3 loops going
on server 2022 and 1 going on ARM64. So far so good. I don't know how
long before calling it good though.
Great, thanks for testing. I'm attaching the complete patch (with
documentation). I'll push it once you're convinced that it fixes the problem,
assuming Takashi agrees. (I think Corinna is unavailable.)
KenFrom 4858e73321a0618a8b1e1060416ef7d546cda895 Mon Sep 17 00:00:00 2001
From: Ken Brown
Date: Sun, 26 Dec 2021 16:42:26 -0500
Subject: [PATCH] Cygwin: fhandler_pipe::get_query_hdl_per_process: avoid a
crash
NtQueryInformationProcess(ProcessHandleInformation) can return
STATUS_SUCCESS with invalid handle data for certain processes
("minimal" processes on Windows 10). This can cause a crash when
there's an attempt to access that data. Fix that by setting
NumberOfHandles to zero before calling NtQueryInformationProcess.
Addresses: https://cygwin.com/pipermail/cygwin-patches/2021q4/011611.html
---
winsup/cygwin/fhandler_pipe.cc | 6 ++
winsup/cygwin/release/3.3.4| 3 +++
2 files changed, 9 insertions(+)
diff --git a/winsup/cygwin/fhandler_pipe.cc b/winsup/cygwin/fhandler_pipe.cc
index 25a092262..2674d154c 100644
--- a/winsup/cygwin/fhandler_pipe.cc
+++ b/winsup/cygwin/fhandler_pipe.cc
@@ -1256,6 +1256,12 @@ fhandler_pipe::get_query_hdl_per_process (WCHAR *name,
HeapAlloc (GetProcessHeap (), 0, nbytes);
if (!phi)
goto close_proc;
+ /* NtQueryInformationProcess can return STATUS_SUCCESS with
+invalid handle data for certain processes. See
+
https://github.com/processhacker/processhacker/blob/master/phlib/native.c#L5754.
+We need to ensure that NumberOfHandles is zero in this
+case to avoid a crash in the loop below. */
+ phi->NumberOfHandles = 0;
status = NtQueryInformationProcess (proc, ProcessHandleInformation,
phi, nbytes, );
if (NT_SUCCESS (status))
diff --git a/winsup/cygwin/release/3.3.4 b/winsup/cygwin/release/3.3.4
index a15684fdb..048426942 100644
--- a/winsup/cygwin/release/3.3.4
+++ b/winsup/cygwin/release/3.3.4
@@ -14,3 +14,6 @@ Bug Fixes
rather than io_handle while neither read() nor select() is called
after the cygwin app is started from non-cygwin app.
Addresses: https://cygwin.com/pipermail/cygwin-patches/2021q4/011587.html
+
+- Avoid a crash when NtQueryInformationProcess returns invalid handle data.
+ Addresses: https://cygwin.com/pipermail/cygwin-patches/2021q4/011611.html
--
2.34.1
Re: [PATCH] fhandler_pipe: add sanity limit to handle loops
On 12/26/2021 11:04 AM, Ken Brown wrote:
On 12/26/2021 10:09 AM, Ken Brown wrote:
1. For some processes, NtQueryInformationProcess(ProcessHandleInformation) can
return STATUS_SUCCESS with invalid handle information. See the comment
starting at line 5754, where it is shown how to detect this.
If I'm right, the following patch should fix the problem:
diff --git a/winsup/cygwin/fhandler_pipe.cc b/winsup/cygwin/fhandler_pipe.cc
index ba6b70f55..4cef3e4ca 100644
--- a/winsup/cygwin/fhandler_pipe.cc
+++ b/winsup/cygwin/fhandler_pipe.cc
@@ -1228,6 +1228,7 @@ fhandler_pipe::get_query_hdl_per_process (WCHAR *name,
HeapAlloc (GetProcessHeap (), 0, nbytes);
if (!phi)
goto close_proc;
+ phi->NumberOfHandles = 0;
status = NtQueryInformationProcess (proc, ProcessHandleInformation,
phi, nbytes, );
if (NT_SUCCESS (status))
Actually, this first hunk should suffice.
@@ -1238,6 +1239,11 @@ fhandler_pipe::get_query_hdl_per_process (WCHAR *name,
while (n_handle < (1L<<20) && status == STATUS_INFO_LENGTH_MISMATCH);
if (!NT_SUCCESS (status))
goto close_proc;
+ if (phi->NumberOfHandles == 0)
+ {
+ HeapFree (GetProcessHeap (), 0, phi);
+ goto close_proc;
+ }
for (ULONG j = 0; j < phi->NumberOfHandles; j++)
{
Jeremy, could you try this?
Ken
Re: [PATCH] fhandler_pipe: add sanity limit to handle loops
On 12/26/2021 10:09 AM, Ken Brown wrote:
1. For some processes, NtQueryInformationProcess(ProcessHandleInformation) can
return STATUS_SUCCESS with invalid handle information. See the comment starting
at line 5754, where it is shown how to detect this.
If I'm right, the following patch should fix the problem:
diff --git a/winsup/cygwin/fhandler_pipe.cc b/winsup/cygwin/fhandler_pipe.cc
index ba6b70f55..4cef3e4ca 100644
--- a/winsup/cygwin/fhandler_pipe.cc
+++ b/winsup/cygwin/fhandler_pipe.cc
@@ -1228,6 +1228,7 @@ fhandler_pipe::get_query_hdl_per_process (WCHAR *name,
HeapAlloc (GetProcessHeap (), 0, nbytes);
if (!phi)
goto close_proc;
+ phi->NumberOfHandles = 0;
status = NtQueryInformationProcess (proc, ProcessHandleInformation,
phi, nbytes, );
if (NT_SUCCESS (status))
@@ -1238,6 +1239,11 @@ fhandler_pipe::get_query_hdl_per_process (WCHAR *name,
while (n_handle < (1L<<20) && status == STATUS_INFO_LENGTH_MISMATCH);
if (!NT_SUCCESS (status))
goto close_proc;
+ if (phi->NumberOfHandles == 0)
+ {
+ HeapFree (GetProcessHeap (), 0, phi);
+ goto close_proc;
+ }
for (ULONG j = 0; j < phi->NumberOfHandles; j++)
{
Jeremy, could you try this?
Ken
Re: [PATCH] fhandler_pipe: add sanity limit to handle loops
On 12/25/2021 11:56 PM, Jeremy Drake wrote: I set up a windows server 2022 VM last night and went nuts stressing pacman/GPGME. I was able to reproduce the issue there: status = 0x, phi->NumberOfHandles = 8261392, n_handle = 256 [#--] 14% assertion "phi->NumberOfHandles <= n_handle" failed: file "../../.././winsup/cygwin/fhandler_pipe.cc", line 1281, function: void* fhandler_pipe::get_query_hdl_per_process(WCHAR*, OBJECT_NAME_INFORMATION*) So it is not something inherent in the x86_64-on-ARM64 emulation but can happen on native x86_64 also. A Google search led me to something that might explain what's going on. Look at the function PhEnumHandlesEx2 starting at line 5713 in https://github.com/processhacker/processhacker/blob/master/phlib/native.c#L5152 Two interesting things: 1. For some processes, NtQueryInformationProcess(ProcessHandleInformation) can return STATUS_SUCCESS with invalid handle information. See the comment starting at line 5754, where it is shown how to detect this. 2. You can use the ReturnLength parameter of NtQueryInformationProcess to see how big a buffer is needed. This might be more efficient than repeatedly doubling the buffer size. Ken
Re: [PATCH] fhandler_pipe: add sanity limit to handle loops
On 12/25/2021 6:00 PM, Jeremy Drake via Cygwin-patches wrote: On Sat, 25 Dec 2021, Jeremy Drake via Cygwin-patches wrote: On Sun, 26 Dec 2021, Takashi Yano wrote: Could you please check the result of the following test case in that ARM64 platform? OK, on Windows 11 ARM64 (same machine as I was testing the assert on): per_process: n_handle=52, NumberOfHandles=52 per_system: n_handle=65536, NumberOfHandles=35331 On GitHub "windows-2022" runner: per_process: n_handle=63, NumberOfHandles=63 per_system: n_handle=65536, NumberOfHandles=34077 On Windows 10 x86_64 (can't remember if it was 21H1 or 21H2): per_process: n_handle=37, NumberOfHandles=37 per_system: n_handle=131072, NumberOfHandles=76069 This completely shoots down the speculation in my last email. Nevertheless, the results you posted earlier do indicate that *sometimes* NtQueryInformationProcess(ProcessHandleInformation) returns STATUS_SUCCESS even if the buffer it's passed is too small. I hope Takashi has an idea what's going on. Ken
Re: [PATCH] fhandler_pipe: add sanity limit to handle loops
On 12/25/2021 2:20 PM, Jeremy Drake via Cygwin-patches wrote: On Sun, 26 Dec 2021, Takashi Yano wrote: Could you please check the result of the following test case in that ARM64 platform? I will probably not be able to get to this until tomorrow at the earliest. But keep in mind the issue I'm seeing is not deterministic - I have to run pacman in a loop validating files via GPGME and eventually it will hang (or hit the assert I added in that version). Most of the time, it's perfectly fine. The results you've already posted seem to indicate that, on your platform, NtQueryInformationProcess(ProcessHandleInformation) returns STATUS_SUCCESS even if the buffer it's passed is too small. [That won't necessarily cause a problem in every one of your pacman runs, so it might appear non-deterministic.] Takashi's test case is designed to verify that that's what's going on. And I think he also wants to see if phi->NumberOfHandles is reliable on your platform even when the buffer is too small. If so, then (on your platform), the do-while loop could be replaced by two calls to NtQueryInformationProcess. The first call would determine how big a buffer is needed, and the second call would use a buffer of that size. But we don't know any of that for sure yet. We also don't know (or at least I don't know) what aspects of your platform are relevant. For example, does this always happen on Windows 11? or on ARM64? Ken
Re: [PATCH] fhandler_pipe: add sanity limit to handle loops
On 12/24/2021 2:42 PM, Jeremy Drake wrote: On Fri, 24 Dec 2021, Ken Brown wrote: I agree that it's hard to see how the line you quoted could cause an exception. But you were using an optimized build, so I'm not sure how reliable the line-number information is. Is it feasible to run your test under strace? If so, you could add some debug_printf statements to examine the values of n_handle and phi->NumberOfHandles. Or what about simply adding an assertion that phi->NumberOfHandles <= n_handle? Ken This issue is not consistent, I was able to reproduce once on x64 by running commands in a loop overnight, but the next time I tried to reproduce I ran for over 24 hours without hitting it. It does seem to happen much more often on Windows on ARM64 (so much so that at first I thought it was an issue with their emulation). With this patch I have not seen the issue again. So can you test your diagnosis by removing your patch and adding an assertion? Also, it seems to have started cropping up in msys2's CI when the GHA runner was switched from "windows-2019" to "windows-2022". And does your patch help here too? I forgot to give a full link to the MSYS2 issue where I have been investigating this: https://github.com/msys2/MSYS2-packages/issues/2752 Actually I think I might see a small bug in the code. But even if I'm right, it would result in n_handle being unnecessarily big rather than too small, so it wouldn't explain what you're seeing. Takashi, in fhandler_pipe.cc:1225, shouldn't you use offsetof(struct _PROCESS_HANDLE_SNAPSHOT_INFORMATION, Handles) instead of 2*sizeof(ULONG_PTR), to take account of possible padding? (And there's a similar issue in fhandler_pipe.cc:1296.) Ken
Re: [PATCH] fhandler_pipe: add sanity limit to handle loops
On 12/23/2021 7:29 PM, Jeremy Drake via Cygwin-patches wrote: On Thu, 23 Dec 2021, Ken Brown wrote: - for (ULONG j = 0; j < phi->NumberOfHandles; j++) + for (ULONG j = 0; j < min(phi->NumberOfHandles, n_handle); j++) Reading the preceding code, I don't see how n_handle could be less than phi->NumberOfHandles. Can you explain? Not really. I saw this stack trace: ... #3 0x000180062f13 in exception::handle (e=0x14cc4f0, frame=, in=, dispatch=) at /c/S/msys2-runtime/src/msys2-runtime/winsup/cygwin/exceptions.cc:835 #4 0x7ff8abd320cf in ntdll!.chkstk () from /c/Windows/SYSTEM32/ntdll.dll #5 0x7ff8abce1454 in ntdll!RtlRaiseException () from /c/Windows/SYSTEM32/ntdll.dll #6 0x7ff8abd30bfe in ntdll!KiUserExceptionDispatcher () from /c/Windows/SYSTEM32/ntdll.dll #7 0x000180092687 in fhandler_pipe::get_query_hdl_per_process (this=this@entry=0x1803700f8, name=name@entry=0x14cc820 L"\\Device\\NamedPipe\\dd50a72ab4668b33-10348-pipe-nt-0x6E6", ntfn=ntfn@entry=0x8000c2ce0) at /c/S/msys2-runtime/src/msys2-runtime/winsup/cygwin/fhandler_pipe.cc:1281 #8 0x000180092bdb in fhandler_pipe::temporary_query_hdl (this=this@entry=0x1803700f8) at /c/S/msys2-runtime/src/msys2-runtime/winsup/cygwin/fhandler_pipe.cc:1190 ... Line 1281 of fhandler_pipe.cc was if (phi->Handles[j].GrantedAccess != access) The only way I could see that causing an exception was if it was reading past the end of the allocated memory, if j was greater than (or equal to) n_handle. Unfortunately, I haven't been able to catch it in a debugger again, so I can't confirm this. I took a core with 'dumper' but gdb doesn't want to load it (it says Core file format not supported, maybe something with msys2's gdb?). I agree that it's hard to see how the line you quoted could cause an exception. But you were using an optimized build, so I'm not sure how reliable the line-number information is. Is it feasible to run your test under strace? If so, you could add some debug_printf statements to examine the values of n_handle and phi->NumberOfHandles. Or what about simply adding an assertion that phi->NumberOfHandles <= n_handle? Ken
Re: [PATCH] fhandler_pipe: add sanity limit to handle loops
On 12/23/2021 6:10 PM, Jeremy Drake via Cygwin-patches wrote:
diff --git a/winsup/cygwin/fhandler_pipe.cc
b/winsup/cygwin/fhandler_pipe.cc
index ba6b70f55..48713a38d 100644
--- a/winsup/cygwin/fhandler_pipe.cc
+++ b/winsup/cygwin/fhandler_pipe.cc
@@ -1239,7 +1239,7 @@ fhandler_pipe::get_query_hdl_per_process (WCHAR *name,
if (!NT_SUCCESS (status))
goto close_proc;
- for (ULONG j = 0; j < phi->NumberOfHandles; j++)
+ for (ULONG j = 0; j < min(phi->NumberOfHandles, n_handle); j++)
Reading the preceding code, I don't see how n_handle could be less than
phi->NumberOfHandles. Can you explain?
{
/* Check for the peculiarity of cygwin read pipe */
const ULONG access = FILE_READ_DATA | FILE_READ_EA
@@ -1309,7 +1309,7 @@ fhandler_pipe::get_query_hdl_per_system (WCHAR *name,
if (!NT_SUCCESS (status))
return NULL;
- for (LONG i = (LONG) shi->NumberOfHandles - 1; i >= 0; i--)
+ for (LONG i = (LONG) min(shi->NumberOfHandles, n_handle) - 1; i >= 0; i--)
Same comment.
Ken
Re: Cygwin 32 doc build failure
On 12/23/2021 12:35 PM, Brian Inglis wrote: Building cygwin 32 doc (with latest packages, git sources, after running winsup/autogen.sh) get the following doc build failure (not on cygwin 64 - all builds okay) - anyone seen this before and any clue where to look? $ ../configure && make ... Making all in doc make[3]: Entering directory '$HOME/src/cygwin/newlib-cygwin/build32/i686-pc-cygwin/winsup/doc' xmlto --skip-validation --with-dblatex pdf -o cygwin-ug-net/ -m ../../../../winsup/doc/fo.xsl ../../../../winsup/doc/cygwin-ug-net.xml Traceback (most recent call last): File "/usr/bin/dblatex", line 3, in from dbtexmf.dblatex import dblatex ModuleNotFoundError: No module named 'dbtexmf' It looks like dblatex needs python3.8. Does your 32-bit installation have python3 pointing to python3.8? $ /usr/sbin/alternatives.exe --display python3 python3 - status is auto. link currently points to /usr/bin/python3.8 /usr/bin/python3.8 - priority 38 Current `best' version is /usr/bin/python3.8. Ken -- 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
Re: libprocps8 and missing free, prockill, pkill, pgrep, pmap, procps, tload, top, uptime, vmstat, w, and watch
On 12/20/2021 12:02 PM, Ken Lobb wrote: I'm probably missing something that needs to be configured, but I'm trying to utilize uptime & vmstat and other performance/load utilities in Cygwin. I installed the libprocps8 package, but none of these utilities can be found. Did I miss something? procps-ng -- 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
Re: setup-x86_64.exe does not start in win10 20H2
On 12/10/2021 12:12 PM, Kutty, Rejeesh wrote: Google says it is part of the Beyond Trust stuff, for security? I couldn't find anything that tells me how to disable it. Is this DLL the problem? Could be. Is Beyond Trust something that you have control over? Can you uninstall it, or temporarily suspend it, or tell it to exclude certain directories? Ken -- 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
Re: setup-x86_64.exe does not start in win10 20H2
On 12/10/2021 9:39 AM, Kutty, Rejeesh wrote: I can't launch setup-x86_64.exe, but setup-x86 runs fine. [...] ModLoad: 7ffd`4371 7ffd`4374a000 C:\WINDOWS\SYSTEM32\privman64.dll What is this and why is it being loaded? Ken -- 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
Re: [ITP] autoconf2.7
On 12/9/2021 5:24 AM, Corinna Vinschen wrote:
On Dec 8 19:46, Achim Gratz wrote:
Achim Gratz writes:
+ case "${WANT_AUTOCONF}" in
+ 2.5|'')
+ WANT_AUTOCONF=2.5
+ case $(autoconf --version 2> /dev/null | head -n 1) in
autoconf*2.[56]?) ;;
*) error "autoconf2.5 is required to build this
package" ;;
+ esac
+ ;;
+ 2.7)
+ WANT_AUTOCONF=2.7
If anybody prefers cygport to default to 2.7, then the "|''" part of the
above patch needs to be moved to the pattern clause for 2.7.
We should do that, IMHO.
I agree, as I already said in a different thread. Either way, there remains the
question of how to get cygport patched. Until that happens, no maintainers can
use autoconf 2.71 unless they patch cygport locally, and no SCALLYWAG builds can
use autoconf 2.71.
Yaakov, any chance you would accept a co-maintainer of cygport (Jon Turney seems
like the obvious choice if he's willing) so that we can move forward on this and
other patches that have been proposed?
Ken
Re: [ANNOUNCEMENT] gd 2.3.3-1 (TEST)
On 9/15/2021 5:13 PM, Ken Brown via Cygwin-announce via Cygwin wrote: The following packages have been uploaded to the Cygwin distribution as test releases: * gd-2.3.3-1 * libgd3-2.3.3-1 * libgd-devel-2.3.3-1 These have now been promoted from test to current. Ken -- 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
Re: [ANNOUNCEMENT] Updated: autoconf-15-1, autoconf2.7-2.71-1
[Redirected from the cygwin list, https://cygwin.com/pipermail/cygwin/2021-December/250149.html] On 12/7/2021 3:08 PM, Ken Brown wrote: On 12/5/2021 3:50 AM, Achim Gratz wrote: Autoconf upstream has stated that the 2.7x releases are not fully backwards compatible. Cygwin therefore chose to provide a new autoconf2.7 package (keeping autoconf2.5 available) and modifying the wrapper script to allow packaging systems to set WANT_AUTOCONF=2.7 to select a newer autoconf version. The default (when no explicit WANT_AUTOCONF is set) is still "2.5", which selects autoconf version 2.69 on Cygwin. As you explained on IRC earlier today, what you meant is that the default for packages built via cygport is still 2.5. The default will change to "2.7" after some period of testing. Cygwin package maintainers are encouraged to set WANT_AUTOCONF=2.7 in their cygport configuration or in individual cygport files in order to check for regressions. I wonder if it would be better to make the default 2.7 in order to more strongly encourage maintainers to try the latter. They can always set WANT_AUTOCONF=2.5 if they can't make it work. But I would bet that most difficulties that arise have already been found and fixed by Fedora. Ken
Re: [ANNOUNCEMENT] Updated: autoconf-15-1, autoconf2.7-2.71-1
On 12/5/2021 3:50 AM, Achim Gratz wrote: Autoconf upstream has stated that the 2.7x releases are not fully backwards compatible. Cygwin therefore chose to provide a new autoconf2.7 package (keeping autoconf2.5 available) and modifying the wrapper script to allow packaging systems to set WANT_AUTOCONF=2.7 to select a newer autoconf version. The default (when no explicit WANT_AUTOCONF is set) is still "2.5", which selects autoconf version 2.69 on Cygwin. As you explained on IRC earlier today, what you meant is that the default for packages built via cygport is still 2.5. The default will change to "2.7" after some period of testing. Cygwin package maintainers are encouraged to set WANT_AUTOCONF=2.7 in their cygport configuration or in individual cygport files in order to check for regressions. I have a comment about this, but I'll follow up on cygwin-apps. Ken -- 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
[GOLDSTAR] Re: [ANNOUNCEMENT] Updated: autoconf-15-1, autoconf2.7-2.71-1
On 12/5/2021 3:50 AM, Achim Gratz wrote: Autoconf has been updated to the latest upstream release 2.71, see the packaging notes below. Additionally the automake wrapper has been updated to the latest upstream version 15 (with some modifications for Cygwin). Great work, thanks for doing this. I second Corinna's gold star recommendation. Ken -- 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
Re: [ITP] autoconf2.7
On 12/2/2021 2:51 PM, Achim Gratz wrote: As discussed in another thread, Cygwin should have an autoconf2.7 package going forward. It builds just out of the box, so here's the ITP for it. Playground (based on autotools2.5, I'll cut the old history in the new repo): https://cygwin.com/git-cygwin-packages/?p=git/cygwin-packages/playground.git;a=shortlog;h=refs/heads/autoconf2.7 CI Build: https://ci.appveyor.com/project/cygwin/scallywag/builds/41751127/job/axabuukd3w4xvsy7 I've switched off the tests, they take too long anyway. You should probably also adopt and update the autoconf package, which provides the ac-wrapper script. The latest upstream version is at https://gitweb.gentoo.org/repo/gentoo.git/plain/sys-devel/autoconf-wrapper/files/ac-wrapper-15.sh Ken
Re: autoconf
On 12/2/2021 8:32 AM, Corinna Vinschen via Cygwin-apps wrote: On Dec 2 14:18, ASSI wrote: As I said, I haven't looked at it in any detail, but it seems that autoconf is already multi-version, so I guess it would be possible to introduce an autoconf2.7 package in addition to the existing two. That's a slightly wonky way to do that when we expect to later on just replace 2.69 with 2.71, though. Don't do that. https://lwn.net/Articles/839395/ autoconf 2.70 and later are new, backward incompatible versions, so they should go into a new-and-shiny-and-not-yet-existing autoconf2.7 package. Does anyone know what other distros are doing? The only one I checked is Fedora. It looks like Fedora 35 simply replaced 2.69 by 2.71, after a long "heads-up" period for maintainers to fix their packages to build with 2.71. https://lists.fedoraproject.org/archives/list/de...@lists.fedoraproject.org/message/6DTWVJRXLC6SOYE6ZBO6KALWMKA2PMFM/ Ken
Re: autoconf
On 12/2/2021 5:15 AM, Jan Nijtmans via Cygwin-apps wrote: Somewhere in cygport, a check is done for the autoconf version, please change this check to allow autoconf 2.71 (as well as 2.59 and 2.69). Then I can put back the "cygautoreconf" line in tcl.cygport. You can do this locally until someone gets around to patching cygport. Just patch /usr/share/cygclass/autotools.cygclass like this: --- autotools.cygclass~ 2020-05-10 12:06:42.0 -0400 +++ autotools.cygclass 2021-12-02 08:14:34.546334100 -0500 @@ -395,7 +395,7 @@ WANT_AUTOCONF=2.5 case $(autoconf --version 2> /dev/null | head -n 1) in - autoconf*2.[56]?) ;; + autoconf*2.[567]?) ;; *) error "autoconf2.5 is required to build this package" ;; esac Ken
Re: Remmina: error while loading shared libraries: cygssh_threads-4.dll: cannot open shared object file: No such file or directory
On 11/28/2021 3:50 PM, Verachten Bruno via Cygwin wrote: Hello there, I installed Remmina tonight, and got this error when launching it: "error while loading shared libraries: cygssh_threads-4.dll: cannot open shared object file: No such file or directory That DLL used to be provided by the libssh4 package, but it's not in the latest version due to upstream changes. As a workaround, you could try reverting to libssh4-0.7.5-1, but I don't know if that will break something else. The real solution is probably to rebuild remmina using the current versions of the development packages. Unfortunately, remmina is orphaned, so someone would have to adopt it or do a non-maintainer upload. Ken -- 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
Re: gnulib m4/threadlib.m4 bug crashing package tests
On 11/28/2021 11:33 AM, Achim Gratz wrote:
Ken Brown via Cygwin-apps writes:
It's gnulib that changed, not Cygwin or gcc/binutils. This is
actually an old issue:
https://cygwin.com/pipermail/cygwin/2010-April/186342.html
I've built the exact same package (man-db) this Febrary without that
problem and now again with that problem (it doesn't help that the test
suite never actually runs the failing executable). The gnulib test
failed (as it still does on 32bit) for 64bit in February, but succeeds
(resulting in gnulib trying to use weak symbols) now.
You're right, I was wrong. Here's the gnulib test program for anyone else who
wants to look at this:
#include
#pragma weak fputs
int main ()
{
return (fputs == NULL);
}
As you said, this used to return 1, but now it returns 0 on 64-bit. Running
under gdb I see
(gdb) p fputs
$1 = {int (const char * restrict, FILE * restrict)} 0x1801b0540
This is a change, and it's actually what one would expect. But, as Dave Korn
explained in
https://cygwin.com/pipermail/cygwin/2010-April/186350.html ,
it doesn't mean that weak symbols on Cygwin behave the way they do on ELF
platforms. So I agree with you that this is a bogus test.
Ken
Re: gnulib m4/threadlib.m4 bug crashing package tests
On 11/28/2021 10:42 AM, Achim Gratz wrote: Yaakov Selkowitz via Cygwin-apps writes: For anyone else who bumps into this, gdb and strace are of no use in debugging this crash. I finally thought to look at the stackdump file, and the second address from the top was in a gnulib file. That was the key clue. Add gl_cv_have_weak=no to cygconf? I'd rather know why the bleeping heck the test suddenly succeeds when it clearly doesn't actually work. In other words, I think the linker should complain, but since it obviously did that before Cygwin 3.2.0 and not after, something must have changed somewhere that prevent s it from doing that. It's gnulib that changed, not Cygwin or gcc/binutils. This is actually an old issue: https://cygwin.com/pipermail/cygwin/2010-April/186342.html Ken
Re: gnulib m4/threadlib.m4 bug crashing package tests
On 11/26/2021 12:34 PM, Brian Inglis wrote:
On 2021-11-26 06:08, Ken Brown via Cygwin-apps wrote:
On 11/25/2021 1:25 PM, Yaakov Selkowitz via Cygwin-apps wrote:
Add gl_cv_have_weak=no to cygconf?
Are you suggesting maintainers should do this, or are you talking about
patching cygport, like this:
diff --git a/cygclass/autotools.cygclass b/cygclass/autotools.cygclass
index 712f437..8b6fdde 100644
--- a/cygclass/autotools.cygclass
+++ b/cygclass/autotools.cygclass
@@ -735,6 +735,14 @@ cygconf() {
export ac_cv_func_mmap_fixed_mapped=yes ;;
esac
+ # Some versions of gnulib's threadlib.m4:gl_WEAK_SYMBOLS
+ # incorrectly report that Cygwin supports weak symbols. See
+ # https://cygwin.com/pipermail/cygwin-apps/2021-September/041587.html.
+ case ${CHOST} in
+ *-*-cygwin*)
+ export gl_cv_have_weak=no ;;
+ esac
+
# packages that use intltool w/o glib-gettext get this wrong
export DATADIRNAME="share"
Normally in a regular/autotools build the maintainer appends these overrides to:
CYGCONF_ARGS=...gl_cv_have_weak=guessing\ no
or to:
src_compile() {
cd ${S}
cygautoreconf
cd ${B}
cygconf ... gl_cv_have_weak=guessing\ no
cygmake
}
cygport already does this for ac_cv_func_mmap_fixed_mapped. That's why I asked
Yaakov to clarify what he had in mind.
Ken
Re: gnulib m4/threadlib.m4 bug crashing package tests
On 11/25/2021 1:25 PM, Yaakov Selkowitz via Cygwin-apps wrote:
Add gl_cv_have_weak=no to cygconf?
Are you suggesting maintainers should do this, or are you talking about patching
cygport, like this:
diff --git a/cygclass/autotools.cygclass b/cygclass/autotools.cygclass
index 712f437..8b6fdde 100644
--- a/cygclass/autotools.cygclass
+++ b/cygclass/autotools.cygclass
@@ -735,6 +735,14 @@ cygconf() {
export ac_cv_func_mmap_fixed_mapped=yes ;;
esac
+ # Some versions of gnulib's threadlib.m4:gl_WEAK_SYMBOLS
+ # incorrectly report that Cygwin supports weak symbols. See
+ # https://cygwin.com/pipermail/cygwin-apps/2021-September/041587.html.
+ case ${CHOST} in
+ *-*-cygwin*)
+ export gl_cv_have_weak=no ;;
+ esac
+
# packages that use intltool w/o glib-gettext get this wrong
export DATADIRNAME="share"
Ken
URL for cygport git repo
According to https://cygwin.com/packages/summary/cygport-src.html, the cygport git repo is at https://cygwin.com/git-cygwin-packages/?p=git/cygwin-packages/cygport.git But that repo is empty. The correct URL seems to be https://cygwin.com/git/?p=cygwin-apps/cygport.git Ken
Re: gnulib m4/threadlib.m4 bug crashing package tests
On 9/29/2021 7:46 PM, Brian Inglis wrote: There is a gnulib bug in threadlib.m4 from at least serial 29 to serial 31 that incorrectly configures Cygwin support of weak references. This leads to SIGSEGV stack smashing crashes with no backtrace @ 0x1 or 0x0005 etc. normally during tests. Akim Demaille on bug-bison referred the issue to bug-gnulib where Bruno Haible diagnosed and patched the problem to appear in m4/threadlib.m4 serial 32: * m4/threadlib.m4 (gl_WEAK_SYMBOLS): Force a "guessing no" result on Cygwin https://lists.gnu.org/archive/html/bug-gnulib/2021-09/msg00068.html [gl_cv_have_weak="guessing no"] The patch has now been applied to bison, wget, and wget2, and I have attached my patches for the copies in those packages, in case anyone else has this issue in their (mainly GNU) packages which may incorporate by inclusion recently updated gnulib m4 macros used in autotools builds. Thanks, Brian. I'm writing to reinforce this warning. I just spent 2 days trying to debug mysterious texinfo crashes that were caused by this bug. I could have saved a lot of time if I had remembered your email and had checked the gnulib version being used by texinfo. For anyone else who bumps into this, gdb and strace are of no use in debugging this crash. I finally thought to look at the stackdump file, and the second address from the top was in a gnulib file. That was the key clue. Ken
[PATCH] Cygwin: fhandler_fifo::raw_read: handle STATUS_PENDING
Patch attached. Takashi, since you wrote the analogous patch for pipes, could
you take a look?
Thanks.
KenFrom 4f47e64b11ed8d47c62fa89e9b971f44b7e9ab75 Mon Sep 17 00:00:00 2001
From: Ken Brown
Date: Tue, 23 Nov 2021 11:40:56 -0500
Subject: [PATCH] Cygwin: fhandler_fifo::raw_read: handle STATUS_PENDING
NtReadFile can return STATUS_PENDING occasionally even in non-blocking
mode. Check for this and wait for NtReadFile to complete. To avoid
code repetition, do this in a static helper function nt_read.
---
winsup/cygwin/fhandler_fifo.cc | 70 +++---
1 file changed, 47 insertions(+), 23 deletions(-)
diff --git a/winsup/cygwin/fhandler_fifo.cc b/winsup/cygwin/fhandler_fifo.cc
index 489ba528c..34bd835ae 100644
--- a/winsup/cygwin/fhandler_fifo.cc
+++ b/winsup/cygwin/fhandler_fifo.cc
@@ -1201,12 +1201,39 @@ fhandler_fifo::release_select_sem (const char *from)
ReleaseSemaphore (select_sem, n_release, NULL);
}
+/* Read from a non-blocking pipe and wait for completion. */
+static NTSTATUS
+nt_read (HANDLE h, HANDLE evt, PIO_STATUS_BLOCK pio, void *in_ptr, size_t& len)
+{
+ NTSTATUS status;
+
+ ResetEvent (evt);
+ status = NtReadFile (h, evt, NULL, NULL, pio, in_ptr, len, NULL, NULL);
+ if (status == STATUS_PENDING)
+{
+ /* Very short-lived */
+ status = NtWaitForSingleObject (evt, FALSE, NULL);
+ if (NT_SUCCESS (status))
+ status = pio->Status;
+}
+ return status;
+}
+
void __reg3
fhandler_fifo::raw_read (void *in_ptr, size_t& len)
{
+ HANDLE evt;
+
if (!len)
return;
+ if (!(evt = CreateEvent (NULL, false, false, NULL)))
+{
+ __seterrno ();
+ len = (size_t) -1;
+ return;
+}
+
while (1)
{
int nconnected = 0;
@@ -1244,17 +1271,15 @@ fhandler_fifo::raw_read (void *in_ptr, size_t& len)
NTSTATUS status;
IO_STATUS_BLOCK io;
- status = NtReadFile (fc_handler[j].h, NULL, NULL, NULL,
- , in_ptr, len, NULL, NULL);
+ status = nt_read (fc_handler[j].h, evt, , in_ptr, len);
switch (status)
{
case STATUS_SUCCESS:
case STATUS_BUFFER_OVERFLOW:
- /* io.Information is supposedly valid in latter case. */
if (io.Information > 0)
{
len = io.Information;
- goto out;
+ goto unlock_out;
}
break;
case STATUS_PIPE_EMPTY:
@@ -1265,7 +1290,7 @@ fhandler_fifo::raw_read (void *in_ptr, size_t& len)
fc_handler[j].set_state (fc_disconnected);
break;
default:
- debug_printf ("NtReadFile status %y", status);
+ debug_printf ("nt_read status %y", status);
fc_handler[j].set_state (fc_error);
break;
}
@@ -1278,8 +1303,7 @@ fhandler_fifo::raw_read (void *in_ptr, size_t& len)
NTSTATUS status;
IO_STATUS_BLOCK io;
- status = NtReadFile (fc_handler[i].h, NULL, NULL, NULL,
-, in_ptr, len, NULL, NULL);
+ status = nt_read (fc_handler[i].h, evt, , in_ptr, len);
switch (status)
{
case STATUS_SUCCESS:
@@ -1290,7 +1314,7 @@ fhandler_fifo::raw_read (void *in_ptr, size_t& len)
if (j < nhandlers)
fc_handler[j].last_read = false;
fc_handler[i].last_read = true;
- goto out;
+ goto unlock_out;
}
break;
case STATUS_PIPE_EMPTY:
@@ -1301,7 +1325,7 @@ fhandler_fifo::raw_read (void *in_ptr, size_t& len)
fc_handler[i].set_state (fc_disconnected);
break;
default:
- debug_printf ("NtReadFile status %y", status);
+ debug_printf ("nt_read status %y", status);
fc_handler[i].set_state (fc_error);
break;
}
@@ -1315,8 +1339,7 @@ fhandler_fifo::raw_read (void *in_ptr, size_t& len)
IO_STATUS_BLOCK io;
nconnected++;
- status = NtReadFile (fc_handler[i].h, NULL, NULL, NULL,
-, in_ptr, len, NULL, NULL);
+ status = nt_read (fc_handler[i].h, evt, , in_ptr, len);
switch (status)
{
case STATUS_SUCCESS:
@@ -1327,7 +1350,7 @@ fhandler_fifo::raw_read (void *in_ptr, size_t& len)
if (j < nhandlers)
fc_handler[j].last_read = false;
fc_handler[i].last_read = true;
- goto out;
+ goto unlock_out;
}
break;
case STATUS_PIPE_EMPTY:
@@ -1337,25 +1360,25 @@ fhandler_fifo::raw_read (void *in_ptr,
[PATCH] Cygwin: fhandler_pipe::raw_read: fix handle leak
Patch attached.From 6d34b62cb8e192071e193516c23419854c3b4127 Mon Sep 17 00:00:00 2001
From: Ken Brown
Date: Tue, 23 Nov 2021 10:13:43 -0500
Subject: [PATCH] Cygwin: fhandler_pipe::raw_read: fix handle leak
Slightly rearrange the code to avoid returning without closing the
event handle.
---
winsup/cygwin/fhandler_pipe.cc | 16 +---
1 file changed, 9 insertions(+), 7 deletions(-)
diff --git a/winsup/cygwin/fhandler_pipe.cc b/winsup/cygwin/fhandler_pipe.cc
index 3cbd434b7..5195b2807 100644
--- a/winsup/cygwin/fhandler_pipe.cc
+++ b/winsup/cygwin/fhandler_pipe.cc
@@ -284,13 +284,6 @@ fhandler_pipe::raw_read (void *ptr, size_t& len)
if (!len)
return;
- if (!(evt = CreateEvent (NULL, false, false, NULL)))
-{
- __seterrno ();
- len = (size_t) -1;
- return;
-}
-
DWORD timeout = is_nonblocking () ? 0 : INFINITE;
DWORD waitret = cygwait (read_mtx, timeout);
switch (waitret)
@@ -314,6 +307,15 @@ fhandler_pipe::raw_read (void *ptr, size_t& len)
len = (size_t) -1;
return;
}
+
+ if (!(evt = CreateEvent (NULL, false, false, NULL)))
+{
+ __seterrno ();
+ len = (size_t) -1;
+ ReleaseMutex (read_mtx);
+ return;
+}
+
while (nbytes < len)
{
ULONG_PTR nbytes_now = 0;
--
2.33.0
Re: ssmtp-config fails on step 6
On 11/19/2021 7:07 PM, Andrey Repin via Cygwin wrote: alternatives is known to make links to nonexistent objects. While this is possible on *NIX, you can only link to existing objects on Windows. You're talking about native Windows symlinks, not Cygwin symlinks. The latter can point to nonexistent objects just as on *NIX. This shouldn't fail unless the user has forced Cygwin to use native Windows symlinks by setting winsymlinks:nativestrict in the CYGWIN environment variable. Kevin, have you done this? If not, do you have any reason to think that alternatives failed to create symlinks? What does 'ls -l /etc/alternatives/mta*' show? On my system I see: $ ls -l /etc/alternatives/mta* lrwxrwxrwx 1 kbrown-admin None 19 2021-11-20 17:04 /etc/alternatives/mta -> /usr/sbin/ssmtp.exe* lrwxrwxrwx 1 kbrown-admin None 19 2021-11-20 17:04 /etc/alternatives/mta-mailq -> /usr/sbin/ssmtp.exe* lrwxrwxrwx 1 kbrown-admin None 19 2021-11-20 17:04 /etc/alternatives/mta-newaliases -> /usr/sbin/ssmtp.exe* lrwxrwxrwx 1 kbrown-admin None 19 2021-11-20 17:04 /etc/alternatives/mta-sendmail -> /usr/sbin/ssmtp.exe* I also have: $ ls -l /usr/sbin/sendmail lrwxrwxrwx 1 kbrown-admin None 21 2021-11-20 17:04 /usr/sbin/sendmail -> /etc/alternatives/mta* and $ /usr/sbin/alternatives.exe --display mta mta - status is manual. link currently points to /usr/sbin/ssmtp.exe /usr/sbin/ssmtp.exe - priority 0 slave mta-sendmail: /usr/sbin/ssmtp.exe slave mta-mailq: /usr/sbin/ssmtp.exe slave mta-newaliases: /usr/sbin/ssmtp.exe Current `best' version is /usr/sbin/ssmtp.exe. Do you see something different on your system? Last question: You said in your first post that "ssmtp-config fails silently" and that you isolated this to the alternatives command failing. What do you mean when you say it failed? Since it failed "silently", do you mean that 'echo $?' showed a nonzero error code? Or do you mean that something is not working as expected? Ken -- 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
Re: [ANNOUNCEMENT] New: unison2.48+4.04.2, unison2.48+4.08.1 [test]
On 9/8/2020 4:57 PM, Andrew Schulman via Cygwin-announce wrote: [...] You can install any number of these packages side-by-side. Separate packages are needed because in order to synchronize your files, you have to run compatible versions of Unison on the client and server. Two Unison executables are compatible if and only if: (1) They have the same first two numbers of the Unison version. For example, all Unison versions 2.48.* are compatible with each other. But if you try to use version 2.51.x to sync with a server running version 2.48.y, Unison will issue an error message about incompatible versions and quit. AND (2) They were built with compatible versions of the OCaml compiler. This old problem reared its ugly head again for me, but I found a simple solution that I'm passing on in case it's of use to others. My situation is that for years I have been syncing my Cygwin system with a Linux system on which I had built unison 2.48.x with OCaml 4.04.x. This is compatible with Cygwin's unison2.48+4.04.2. But I just added a second Linux system that I want to keep in sync with my other systems, and this one comes with a Unison compatible with Cygwin's unison2.48+4.08.1. It turns out that Unison's upstream maintainer is making Linux binaries available, built with various different versions of OCaml. See, for examples, the Assets listed under v2.51.4 at https://github.com/bcpierce00/unison/releases So if I install unison2.51 on Cygwin and install the appropriate binary in ~/bin on both of the Linux machines that I want to sync with, then everything works. For example, if I see $ unison -version unison version 2.51.4 (ocaml 4.12.0) on Cygwin, then I know that I need to use unison-v2.51.4+ocaml-4.12.0+x86_64.linux.tar.gz on the Linux machines. It's still annoying, but not as bad as it used to be. Ken -- 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
Re: [PATCH] Cygwin: pipe: Suppress unnecessary set_pipe_non_blocking() call.
On 11/17/2021 3:08 AM, Takashi Yano wrote: - Call set_pipe_non_blocking(false) only if the pipe will be really inherited to non-cygwin process. LGTM, but Corinna should probably take a quick look too, since I'm not very familiar with this part of the code. Ken
Re: [PATCH v3] Cygwin: pipe: Handle STATUS_PENDING even for nonblocking mode.
On 11/16/2021 9:33 AM, Takashi Yano wrote: - NtReadFile() and NtWriteFile() seems to return STATUS_PENDING occasionally even in nonblocking mode. This patch adds handling for STATUS_PENDING in nonblocking mode. I haven't tested (I assume you have), but LGTM except for two typos below. +- Fix issue that pipe read()/write() occationally returns a garnage occasionally garbage Ken
Re: cygport build injecting /usr/lib/gcc/x86_64-pc-cygwin/7.4.0/ paths
On 11/12/2021 12:50 PM, Brian Inglis wrote: Got these errors trying to build latest ncurses on my system, so retried on scallywag and got same result, with no clue where that is coming from! There are no files in the tarball, repo, or build dirs containing 7.4.0 Those paths come from /usr/bin/libtool. There's some discussion of this issue in https://mingw-users.narkive.com/Mx8FQPRf/libtool-hard-coded-paths , which even mentions the ncurses problem. I don't know enough about libtool to suggest the best solution, but probably others on the list do. Ken -- 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
Re: Another pipe-related problem?
On 11/10/2021 1:42 PM, Henry S. Thompson wrote: Ken Brown writes: The good news is that the bug doesn't seem to occur in XEmacs 21.4 (on 32-bit Cygwin). So one way to approach this would be to bisect the XEmacs git repo to find the commit that introduced the bug. You'd probably have to do the work on 32-bit Cygwin since, if I remember correctly, XEmacs 21.4 didn't build on 64-bit Cygwin. Right, although I _suspect_ it will be in 64-bit-only code. Easy enough to find out, once I resurrect a 32-bit install on a spare machine that I can run 3.3 on (I use XEmacs all day every day from my day job, so I need to stay with 3.2 until we fix this). I had actually tested the 32-bit case before suggesting the bisection. The bug does occur there too. And, as Andrey said, you don't need to use a spare machine. You can have as many parallel Cygwin installs as you want on a single machine, some 64-bit and some 32-bit. Ken -- 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
Re: [PATCH 0/2] Fix a bad case of absolute path handling
On 11/11/2021 4:47 AM, Corinna Vinschen wrote: On Nov 10 17:22, Ken Brown wrote: I can't immediately think of anything. But is it really impossible to phase out DOS path support over a period of time? We could start with a HEADS-UP, asking for comments, then a deprecation announcement, then something like the old dosfilewarning option, then a more forceful warning that can't be turned off, and finally removal of support. This could be done over a period of several years (not sure how many). Yeah, we might try again. Just not over years, we'll probably lose track over time. I'd appreciate a shorter period with a chance to see the end. The problem is that people are probably using DOS paths all the time. Makefiles and scripts mixing Cygwin and DOS tools come to mind. So maybe an RFC email would be useful rather than a HEADS-UP, just to see how widespread it is. For the time being, I wonder if we could start with isabspath being always strict so at least X: isn't an abspath at all. Sounds reasonable. We could also put lines like # C:/ on /c type ntfs (binary,posix=0) into the default /etc/fstab. Commented out, you mean? Just as hint? Yes. We could do that. Personally I don't like these shortcuts, I rather use a shorter cygdrive prefix, like /mnt, but I see how this could convince people. Scripts with mixed tools will always be a problem, though. Ken
Re: [PATCH 0/2] Fix a bad case of absolute path handling
On 11/10/2021 3:32 PM, corinna-cyg...@cygwin.com wrote: From: Corinna Vinschen As I told Takashi in PM, I will try to more often send patches to the cygwin-patches ML before pushing them, so there's a chance to chime in. LGTM. This patch series is supposed to address the `rm -rf' problem reported in https://cygwin.com/pipermail/cygwin/2021-November/249837.html It was always frustrating, having to allow DOS drive letter paths for backward compatibility. This here is another case of ambiguity, triggered by the `isabspath' macro handling "X:" as absolute path, even without the trailing slash or backslash. Check out the 2nd patch for a more detailed description. While at it, I wonder if we might have a chance to fix these ambiguities in a better way. For instance, consider this: $ mkdir -p test/c: $ cd test As non-admin: $ touch c:/foo touch: cannot touch 'c:/foo': Permission denied As admin, even worse: $ touch c:/foo $ ls /cygdrive/c/foo foo As long as we support DOS paths as input, I have a hard time to see how to fix this, but maybe we can at least minimize the ambiguity somehow. I can't immediately think of anything. But is it really impossible to phase out DOS path support over a period of time? We could start with a HEADS-UP, asking for comments, then a deprecation announcement, then something like the old dosfilewarning option, then a more forceful warning that can't be turned off, and finally removal of support. This could be done over a period of several years (not sure how many). We could also put lines like # C:/ on /c type ntfs (binary,posix=0) into the default /etc/fstab. Ken
Re: New pipe code means a gold star is merited
On 11/10/2021 1:45 PM, Henry S. Thompson via Cygwin wrote: for Ken Brown and Takashi Yano, don't you think? Even though we made XEmacs unusable?!? :) But seriously, it was a joint effort among the two of us and Corinna. Thanks. Ken -- 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
Re: Another pipe-related problem?
On 11/10/2021 12:23 PM, Henry S. Thompson wrote: Ken Brown via Cygwin writes: On 11/9/2021 9:53 PM, Ken Brown via Cygwin wrote: Back to the drawing board. It finally occurred to me to stop looking for a bug in fhandler_pipe::raw_read and instead see if something is in fact repeatedly writing to the pipe, so that drain_signal_event_pipe never finishes. Putting a breakpoint at fhandler_pipe::raw_write, I found that this is in fact the case. While the main thread is repeatedly reading from the pipe, a second thread is repeatedly writing to it. Here's the backtrace of that thread: Argh. Thanks for the hard labour on this. This is not a part of the XEmacs code I have any experience of. Is there any clue you can give about how things changed in all the September commits to fhandler_pipe.cc that might have exposed the XEmacs bug? The main change was that we stopped using Win32 Overlapped I/O (https://docs.microsoft.com/en-us/windows/win32/sync/synchronization-and-overlapped-input-and-output) and switched to using the NT API. As a result, pipe I/O became much more efficient. It wouldn't surprise me if the efficiency alone is what exposed the bug. The good news is that the bug doesn't seem to occur in XEmacs 21.4 (on 32-bit Cygwin). So one way to approach this would be to bisect the XEmacs git repo to find the commit that introduced the bug. You'd probably have to do the work on 32-bit Cygwin since, if I remember correctly, XEmacs 21.4 didn't build on 64-bit Cygwin. Ken -- 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
Re: Another pipe-related problem?
On 11/9/2021 9:53 PM, Ken Brown via Cygwin wrote:
Back to the drawing board.
It finally occurred to me to stop looking for a bug in fhandler_pipe::raw_read
and instead see if something is in fact repeatedly writing to the pipe, so that
drain_signal_event_pipe never finishes. Putting a breakpoint at
fhandler_pipe::raw_write, I found that this is in fact the case. While the main
thread is repeatedly reading from the pipe, a second thread is repeatedly
writing to it. Here's the backtrace of that thread:
#0 fhandler_pipe_fifo::raw_write (this=0x18039f370, ptr=0x2c4ca3b, len=1)
at ../../../../temp/winsup/cygwin/fhandler_pipe.cc:430
#1 0x00018006f39a in fhandler_base::write (this=0x18039f370,
ptr=0x2c4ca3b, len=1) at ../../../../temp/winsup/cygwin/fhandler.cc:907
#2 0x000180158fd1 in write (fd=4, ptr=0x2c4ca3b, len=1)
at ../../../../temp/winsup/cygwin/syscalls.cc:1360
#3 0x0001801b9b5b in _sigfe () at sigfe.s:35
#4 0x0001006ae471 in retry_write_1 (fildes=4, buf=0x2c4ca3b, nbyte=1,
allow_quit=0) at sysdep.c:2364
#5 0x0001006ae581 in retry_write (fildes=4, buf=0x2c4ca3b, nbyte=1)
at sysdep.c:2386
#6 0x0001004b3ba5 in signal_fake_event () at event-unixoid.c:149
#7 0x000100691060 in alarm_signal (signo=14) at signal.c:559
#8 0x0001006ec6e4 in mswindows_raise (nsig=14) at win32.c:694
#9 0x0001006ec72d in setitimer_helper_proc (unused_uID=96, unused_uMsg=0,
dwUser=14, unused_dw1=0, unused_dw2=0) at win32.c:742
#10 0x7ffb363c2811 in WINMM!PlaySoundW () from /c/WINDOWS/SYSTEM32/WINMM.dll
#11 0x00018004771c in _cygtls::call2 (this=0x2c4ce00,
func=0x7ffb363c26c0 , arg=0x0, buf=0x2c4cce0)
at ../../../../temp/winsup/cygwin/cygtls.cc:40
#12 0x0001800476c1 in _cygtls::call (
func=0x7ffb363c26c0 , arg=0x0)
at ../../../../temp/winsup/cygwin/cygtls.cc:27
#13 0x0001800e4f15 in threadfunc_fe (arg=0x0)
at ../../../../temp/winsup/cygwin/init.cc:28
#14 0x7ffb43da7034 in KERNEL32!BaseThreadInitThunk ()
from /c/WINDOWS/System32/KERNEL32.DLL
#15 0x7ffb448c2651 in ntdll!RtlUserThreadStart ()
from /c/WINDOWS/SYSTEM32/ntdll.dll
#16 0x in ?? ()
Backtrace stopped: previous frame inner to this frame (corrupt stack?)
This looks to me like an XEmacs bug that happens to be triggered by the new pipe
code, although maybe there's also a Cygwin bug that I'm not seeing. The comment
at the beginning of signal_fake_event might be relevant:
void
signal_fake_event (void)
{
Rawbyte rbyte = 0;
/* We do the write always. Formerly I tried to "optimize" this
by setting a flag indicating whether we're blocking and only
doing the write in that case, but there is a race condition
if the signal occurs after we've checked for the signal
occurrence (which could occur in many places throughout
an iteration of the command loop, e.g. in status_notify()),
but before we set the blocking flag.
This should be OK as long as write() is reentrant, which I'm fairly
sure it is since it's a system call. */
if (signal_event_pipe_initialized)
/* In case a signal comes through while we're dumping */
{
int old_errno = errno;
retry_write (signal_event_pipe[1], , 1);
errno = old_errno;
}
}
Ken
--
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
Re: Another pipe-related problem?
On 11/9/2021 5:20 PM, Ken Brown via Cygwin wrote:
On 11/9/2021 5:16 PM, Ken Brown via Cygwin wrote:
On 11/9/2021 9:11 AM, Ken Brown via Cygwin wrote:
On 11/9/2021 5:55 AM, Henry S. Thompson wrote:
As you may know, the XEmacs situation is complicated. The old source
repo (bitbucket.org/xemacs) no longer exists. There's a fork that's
still being maintained, but it's not widely publicised. That's the
one I'm working with -- are you aware of this.
I was aware that the bitbucket repo didn't exist, because I tried to get the
sources there. But I didn't know about the fork. Please point me to it, or
just make a tarball available to me somehow.
Here are the immediate contexts from the sources for the xemacs
sources in the above backtrace, might be enough to check your
hypothesis:
sysdep.c:
retry_read_1 (int fildes, void *buf, size_t nbyte, int allow_quit)
{
ssize_t rtnval;
while ((rtnval = read (fildes, buf, nbyte)) == -1
&& (errno == EINTR)) <<<<<<<<<<<<<<<<<<<<
{
if (allow_quit)
QUIT;
}
return rtnval;
}
I'll have to reproduce the hang myself in order to test this (or maybe you
could test it), but I now have a new guess: If the read call above keeps
failing with EINTR, then we're in an infinite loop. This could happen
because of the following code in fhandler_pipe::raw_read:
DWORD waitret = cygwait (read_mtx, timeout);
switch (waitret)
{
case WAIT_OBJECT_0:
break;
case WAIT_TIMEOUT:
set_errno (EAGAIN);
len = (size_t) -1;
return;
default:
set_errno (EINTR);
len = (size_t) -1;
return;
}
Takashi, is EINTR really the appropriate errno in the default case? Isn't
cygwait supposed to handle signals?
I was able to build XEmacs and reproduce the problem. My guess was wrong,
though my question to Takashi still stands. I think the infinite loop is
actually caused by a bug in fhandler_pipe::raw_read that only affects
non-blocking pipes (which is what we have in XEmacs).
Consider the following code in fhandler_pipe::raw_read:
status = NtReadFile (get_handle (), evt, NULL, NULL, , ptr,
len1, NULL, NULL);
if (evt && status == STATUS_PENDING) <<<<<<<<<<<<<<<<<<<<<<<<<<<<
{
waitret = cygwait (evt, INFINITE, cw_cancel | cw_sig);
[...]
}
In the non-blocking case, evt == NULL, but we still might have status ==
STATUS_PENDING. We then should wait on get_handle() to let NtReadFile finish.
By not waiting, we end up using a garbage value from io.Information, leading
to an infinite loop in drain_signal_event_pipe.
Nope, that doesn't seem to be the issue. Even after fixing this, I still see an
infinite loop. Probably NtReadFile finishes quickly enough that io.Information
is in fact valid by the time we test it. Back to the drawing board.
BTW, a quick glance at raw_write suggests that there might be a similar bug
there, but I'll have to look more closely.
Ken
--
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
Re: Another pipe-related problem?
On 11/9/2021 7:37 PM, Takashi Yano via Cygwin wrote:
On Wed, 10 Nov 2021 09:16:13 +0900
Takashi Yano wrote:
On Wed, 10 Nov 2021 08:48:22 +0900
Takashi Yano wrote:
On Wed, 10 Nov 2021 08:29:32 +0900
Takashi Yano wrote:
On Wed, 10 Nov 2021 08:22:45 +0900
Takashi Yano wrote:
On Tue, 9 Nov 2021 09:11:28 -0500
Ken Brown wrote:
I'll have to reproduce the hang myself in order to test this (or maybe you could
test it), but I now have a new guess: If the read call above keeps failing with
EINTR, then we're in an infinite loop. This could happen because of the
following code in fhandler_pipe::raw_read:
DWORD waitret = cygwait (read_mtx, timeout);
switch (waitret)
{
case WAIT_OBJECT_0:
break;
case WAIT_TIMEOUT:
set_errno (EAGAIN);
len = (size_t) -1;
return;
default:
set_errno (EINTR);
len = (size_t) -1;
return;
}
Takashi, is EINTR really the appropriate errno in the default case? Isn't
cygwait supposed to handle signals?
I assume cygwait() returns WAIT_SIGNALED when signalled
by SIGINT, SIGTERM, SIGTSTP, etc... In this case, EINTR
should return I think.
Is it wrong?
Ah, if SA_RESTART is set, we should continue to read even
if signalled...
[...]
No, we don't have to do that because cygwait() do the same
internally. cygwain() returns WAIT_SIGNALED when signalled
only if SA_RESTART is not set. So, the current code LGTM.
Ah, however, should we handle WAIT_CANCELED here and call
pthread::static_cancel_self() as following?
DWORD waitret = cygwait (read_mtx, timeout);
switch (waitret)
{
case WAIT_OBJECT_0:
break;
case WAIT_TIMEOUT:
set_errno (EAGAIN);
len = (size_t) -1;
return;
WAIT_SIGNALED:
set_errno (EINTR);
len = (size_t) -1;
return;
WAIT_CANCELED:
pthread::static_cancel_self ();
/* NOTREACHED */
default:
/* Should not reach here. */
__seterrno ();
len = (slze_t) -1;
return;
}
This looks better to me. I think the default case actually could be reached if
WFMO returns WAIT_FAILED (admittedly unlikely).
Ken
--
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
Re: Another pipe-related problem?
On 11/9/2021 5:16 PM, Ken Brown via Cygwin wrote:
On 11/9/2021 9:11 AM, Ken Brown via Cygwin wrote:
On 11/9/2021 5:55 AM, Henry S. Thompson wrote:
As you may know, the XEmacs situation is complicated. The old source
repo (bitbucket.org/xemacs) no longer exists. There's a fork that's
still being maintained, but it's not widely publicised. That's the
one I'm working with -- are you aware of this.
I was aware that the bitbucket repo didn't exist, because I tried to get the
sources there. But I didn't know about the fork. Please point me to it, or
just make a tarball available to me somehow.
Here are the immediate contexts from the sources for the xemacs
sources in the above backtrace, might be enough to check your
hypothesis:
sysdep.c:
retry_read_1 (int fildes, void *buf, size_t nbyte, int allow_quit)
{
ssize_t rtnval;
while ((rtnval = read (fildes, buf, nbyte)) == -1
&& (errno == EINTR)) <<<<<<<<<<<<<<<<<<<<
{
if (allow_quit)
QUIT;
}
return rtnval;
}
I'll have to reproduce the hang myself in order to test this (or maybe you
could test it), but I now have a new guess: If the read call above keeps
failing with EINTR, then we're in an infinite loop. This could happen because
of the following code in fhandler_pipe::raw_read:
DWORD waitret = cygwait (read_mtx, timeout);
switch (waitret)
{
case WAIT_OBJECT_0:
break;
case WAIT_TIMEOUT:
set_errno (EAGAIN);
len = (size_t) -1;
return;
default:
set_errno (EINTR);
len = (size_t) -1;
return;
}
Takashi, is EINTR really the appropriate errno in the default case? Isn't
cygwait supposed to handle signals?
I was able to build XEmacs and reproduce the problem. My guess was wrong,
though my question to Takashi still stands. I think the infinite loop is
actually caused by a bug in fhandler_pipe::raw_read that only affects
non-blocking pipes (which is what we have in XEmacs).
Consider the following code in fhandler_pipe::raw_read:
status = NtReadFile (get_handle (), evt, NULL, NULL, , ptr,
len1, NULL, NULL);
if (evt && status == STATUS_PENDING) <<<<<<<<<<<<<<<<<<<<<<<<<<<<
{
waitret = cygwait (evt, INFINITE, cw_cancel | cw_sig);
[...]
}
In the non-blocking case, evt == NULL, but we still might have status ==
STATUS_PENDING. We then should wait on get_handle() to let NtReadFile finish.
By not waiting, we end up using a garbage value from io.Information, leading to
an infinite loop in drain_signal_event_pipe.
I'll try to fix this.
BTW, a quick glance at raw_write suggests that there might be a similar bug
there, but I'll have to look more closely.
Ken
--
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
Re: Another pipe-related problem?
On 11/9/2021 9:11 AM, Ken Brown via Cygwin wrote:
On 11/9/2021 5:55 AM, Henry S. Thompson wrote:
As you may know, the XEmacs situation is complicated. The old source
repo (bitbucket.org/xemacs) no longer exists. There's a fork that's
still being maintained, but it's not widely publicised. That's the
one I'm working with -- are you aware of this.
I was aware that the bitbucket repo didn't exist, because I tried to get the
sources there. But I didn't know about the fork. Please point me to it, or
just make a tarball available to me somehow.
Here are the immediate contexts from the sources for the xemacs
sources in the above backtrace, might be enough to check your
hypothesis:
sysdep.c:
retry_read_1 (int fildes, void *buf, size_t nbyte, int allow_quit)
{
ssize_t rtnval;
while ((rtnval = read (fildes, buf, nbyte)) == -1
&& (errno == EINTR)) <<<<<<<<<<<<<<<<<<<<
{
if (allow_quit)
QUIT;
}
return rtnval;
}
I'll have to reproduce the hang myself in order to test this (or maybe you could
test it), but I now have a new guess: If the read call above keeps failing with
EINTR, then we're in an infinite loop. This could happen because of the
following code in fhandler_pipe::raw_read:
DWORD waitret = cygwait (read_mtx, timeout);
switch (waitret)
{
case WAIT_OBJECT_0:
break;
case WAIT_TIMEOUT:
set_errno (EAGAIN);
len = (size_t) -1;
return;
default:
set_errno (EINTR);
len = (size_t) -1;
return;
}
Takashi, is EINTR really the appropriate errno in the default case? Isn't
cygwait supposed to handle signals?
I was able to build XEmacs and reproduce the problem. My guess was wrong,
though my question to Takashi still stands. I think the infinite loop is
actually caused by a bug in fhandler_pipe::raw_read that only affects
non-blocking pipes (which is what we have in XEmacs).
Consider the following code in fhandler_pipe::raw_read:
status = NtReadFile (get_handle (), evt, NULL, NULL, , ptr,
len1, NULL, NULL);
if (evt && status == STATUS_PENDING) <<<<<<<<<<<<<<<<<<<<<<<<<<<<
{
waitret = cygwait (evt, INFINITE, cw_cancel | cw_sig);
[...]
}
In the non-blocking case, evt == NULL, but we still might have status ==
STATUS_PENDING. We then should wait on get_handle() to let NtReadFile finish.
By not waiting, we end up using a garbage value from io.Information, leading to
an infinite loop in drain_signal_event_pipe.
I'll try to fix this.
Ken
--
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
Re: Another pipe-related problem?
On 11/9/2021 5:55 AM, Henry S. Thompson wrote:
Ken Brown via Cygwin writes:
On 11/8/2021 8:12 AM, Henry S. Thompson via Cygwin wrote:
Running on Windows-10 21H1
With Cygwin 3.3.0 and 3.3.1 I get a hang every time I try to launch XEmacs:
..
#6 0x00018013ffcc in read (fd=3, ptr=0x0bc0, len=)
at /usr/src/debug/cygwin-3.3.1-1/winsup/cygwin/dtable.h:64
#7 0x00018018e88b in _sigfe () at sigfe.s:35
#8 0x00010066a11d in retry_read_1 (fildes=3, buf=0x0bc0, nbyte=128,
allow_quit=0) at sysdep.c:2425
#9 0x00010066a171 in retry_read (fildes=3, buf=0x0bc0, nbyte=128)
at sysdep.c:2437
#10 0x000100494d86 in drain_signal_event_pipe () at event-unixoid.c:159
#11 0x00010056d1dc in mswindows_need_event (badly_p=1) at event-msw.c:1432
This is an old executable, has worked since 2015 (!), but recompiling
didn't help. Reverting to 3.2 lets it run again.
This backtrace doesn't match the source of Cygwin's XEmacs package
(which exists on 32-bit Cygwin only), so I assume you built this
yourself, using a different version of XEmacs. Cygwin's XEmacs
doesn't hang for me.
Thanks for looking in to this!
And you're right, it's a local build. I was responsible for producing
the 64-bit XEmacs back in 2015, but could never get a Visual Studio
build to work at that time, so it was never released.
Please provide build instructions for the version you compiled.
As you may know, the XEmacs situation is complicated. The old source
repo (bitbucket.org/xemacs) no longer exists. There's a fork that's
still being maintained, but it's not widely publicised. That's the
one I'm working with -- are you aware of this.
I was aware that the bitbucket repo didn't exist, because I tried to get the
sources there. But I didn't know about the fork. Please point me to it, or
just make a tarball available to me somehow.
Here are the immediate contexts from the sources for the xemacs
sources in the above backtrace, might be enough to check your
hypothesis:
sysdep.c:
retry_read_1 (int fildes, void *buf, size_t nbyte, int allow_quit)
{
ssize_t rtnval;
while ((rtnval = read (fildes, buf, nbyte)) == -1
&& (errno == EINTR)) <<<<<<<<<<<<<<<<<<<<
{
if (allow_quit)
QUIT;
}
return rtnval;
}
I'll have to reproduce the hang myself in order to test this (or maybe you could
test it), but I now have a new guess: If the read call above keeps failing with
EINTR, then we're in an infinite loop. This could happen because of the
following code in fhandler_pipe::raw_read:
DWORD waitret = cygwait (read_mtx, timeout);
switch (waitret)
{
case WAIT_OBJECT_0:
break;
case WAIT_TIMEOUT:
set_errno (EAGAIN);
len = (size_t) -1;
return;
default:
set_errno (EINTR);
len = (size_t) -1;
return;
}
Takashi, is EINTR really the appropriate errno in the default case? Isn't
cygwait supposed to handle signals?
Ken
--
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
Re: Another pipe-related problem?
On 11/8/2021 9:35 AM, Ken Brown via Cygwin wrote: On 11/8/2021 8:12 AM, Henry S. Thompson via Cygwin wrote: Running on Windows-10 21H1 With Cygwin 3.3.0 and 3.3.1 I get a hang every time I try to launch XEmacs: #0 0x7ffdf31cd474 in ntdll!ZwQueryTimer () from /c/Windows/SYSTEM32/ntdll.dll #1 0x0001800479fa in cygwait (object=, timeout=0x09a0, timeout@entry=0x0, mask=mask@entry=5) at /usr/x86_64-pc-cygwin/sys-root/usr/include/w32api/psdk_inc/intrin-impl.h:838 #2 0x00018008f716 in cygwait (mask=, howlong=, h=) at /usr/src/debug/cygwin-3.3.1-1/winsup/cygwin/cygwait.h:45 #3 cygwait (howlong=, h=) at /usr/src/debug/cygwin-3.3.1-1/winsup/cygwin/cygwait.h:51 #4 fhandler_pipe::raw_read (this=0x18034fe80, ptr=0x0bc0, len=@0x0b40: 128) at /usr/src/debug/cygwin-3.3.1-1/winsup/cygwin/fhandler_pipe.cc:296 #5 0x000180069244 in fhandler_base::read (this=0x18034fe80, in_ptr=0x0bc0, len=@0x0b40: 128) at /usr/src/debug/cygwin-3.3.1-1/winsup/cygwin/fhandler.cc:819 #6 0x00018013ffcc in read (fd=3, ptr=0x0bc0, len=) at /usr/src/debug/cygwin-3.3.1-1/winsup/cygwin/dtable.h:64 #7 0x00018018e88b in _sigfe () at sigfe.s:35 #8 0x00010066a11d in retry_read_1 (fildes=3, buf=0x0bc0, nbyte=128, allow_quit=0) at sysdep.c:2425 #9 0x00010066a171 in retry_read (fildes=3, buf=0x0bc0, nbyte=128) at sysdep.c:2437 #10 0x000100494d86 in drain_signal_event_pipe () at event-unixoid.c:159 #11 0x00010056d1dc in mswindows_need_event (badly_p=1) at event-msw.c:1432 This is an old executable, has worked since 2015 (!), but recompiling didn't help. Reverting to 3.2 lets it run again. This backtrace doesn't match the source of Cygwin's XEmacs package (which exists on 32-bit Cygwin only), so I assume you built this yourself, using a different version of XEmacs. Cygwin's XEmacs doesn't hang for me. Please provide build instructions for the version you compiled. Your backtrace shows that fhandler_pipe::raw_read is blocked waiting for a mutex Alternatively, XEmacs might be in an infinite loop starting at frame 8 or 9, repeatedly trying to read and failing because it can't get the mutex. Either way, we need the sources in order to go further. Ken -- 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
Re: Another pipe-related problem?
On 11/8/2021 8:12 AM, Henry S. Thompson via Cygwin wrote: Running on Windows-10 21H1 With Cygwin 3.3.0 and 3.3.1 I get a hang every time I try to launch XEmacs: #0 0x7ffdf31cd474 in ntdll!ZwQueryTimer () from /c/Windows/SYSTEM32/ntdll.dll #1 0x0001800479fa in cygwait (object=, timeout=0x09a0, timeout@entry=0x0, mask=mask@entry=5) at /usr/x86_64-pc-cygwin/sys-root/usr/include/w32api/psdk_inc/intrin-impl.h:838 #2 0x00018008f716 in cygwait (mask=, howlong=, h=) at /usr/src/debug/cygwin-3.3.1-1/winsup/cygwin/cygwait.h:45 #3 cygwait (howlong=, h=) at /usr/src/debug/cygwin-3.3.1-1/winsup/cygwin/cygwait.h:51 #4 fhandler_pipe::raw_read (this=0x18034fe80, ptr=0x0bc0, len=@0x0b40: 128) at /usr/src/debug/cygwin-3.3.1-1/winsup/cygwin/fhandler_pipe.cc:296 #5 0x000180069244 in fhandler_base::read (this=0x18034fe80, in_ptr=0x0bc0, len=@0x0b40: 128) at /usr/src/debug/cygwin-3.3.1-1/winsup/cygwin/fhandler.cc:819 #6 0x00018013ffcc in read (fd=3, ptr=0x0bc0, len=) at /usr/src/debug/cygwin-3.3.1-1/winsup/cygwin/dtable.h:64 #7 0x00018018e88b in _sigfe () at sigfe.s:35 #8 0x00010066a11d in retry_read_1 (fildes=3, buf=0x0bc0, nbyte=128, allow_quit=0) at sysdep.c:2425 #9 0x00010066a171 in retry_read (fildes=3, buf=0x0bc0, nbyte=128) at sysdep.c:2437 #10 0x000100494d86 in drain_signal_event_pipe () at event-unixoid.c:159 #11 0x00010056d1dc in mswindows_need_event (badly_p=1) at event-msw.c:1432 This is an old executable, has worked since 2015 (!), but recompiling didn't help. Reverting to 3.2 lets it run again. This backtrace doesn't match the source of Cygwin's XEmacs package (which exists on 32-bit Cygwin only), so I assume you built this yourself, using a different version of XEmacs. Cygwin's XEmacs doesn't hang for me. Please provide build instructions for the version you compiled. Your backtrace shows that fhandler_pipe::raw_read is blocked waiting for a mutex, but I can't tell why without seeing the XEmacs source. My guess, just from looking at the function names, is that XEmacs is mixing POSIX reads with Win32 reads, messing up the mutex handling. Ken -- 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
Re: 3.3.0: Possible regression in cygwin DLL (Win10); fixed in snapshot
On 11/5/2021 4:08 PM, Ken Brown via Cygwin wrote: On 11/5/2021 3:41 PM, Takashi Yano via Cygwin wrote: What about setting pipe mode to byte by default? I have a vague recollection that this caused some other problem, but I'll have to review the email discussions from a few months ago. I'm traveling at the moment and won't get to this for a few days. I found it: https://cygwin.com/pipermail/cygwin-developers/2021-August/012219.html Ken -- 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
Re: 3.3.0: Possible regression in cygwin DLL (Win10); fixed in snapshot
Hi Takashi, On 11/5/2021 3:41 PM, Takashi Yano via Cygwin wrote: Thanks much for the detailed steps. I could reproduce the problem. It seems that the cause is the overhaul for the pipe implementation. I also found the workaround for this issue. Please try: export CYGWIN=pipe_byte Corinna, Ken, What about setting pipe mode to byte by default? I have a vague recollection that this caused some other problem, but I'll have to review the email discussions from a few months ago. I'm traveling at the moment and won't get to this for a few days. In the meantime, could you explain (probably on cygwin-developers) why message mode causes the reported issue? Also, does the problem occur only when there are non-Cygwin apps involved? Thanks. Ken -- 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
Re: cat fifo hang [Re: [ANNOUNCEMENT] cygwin 3.3.0-0.2.6c1f49f83fde (TEST)]
On 10/17/2021 6:15 PM, Ken Brown via Cygwin wrote: On 10/17/2021 4:52 PM, Chris Roehrig wrote: Here's a script that pretty reliably hangs cat after some iterations. [...] Thanks! I can reproduce the hang. I'll look into it. I've done some debugging and have followed up on the cygwin-developers list: https://cygwin.com/pipermail/cygwin-developers/2021-October/012429.html Let's hope someone there can figure out what the problem is. Thanks again for reporting this and, especially, for providing a simple test case. Ken -- 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
Re: emacs 28.0.60-1.f7e6c199bf (TEST)
On 10/18/2021 3:15 PM, Jim Reisert AD1C wrote: Here is a macro I use quite frequently, with a line like this: # New Exception Call: PD0TEST/J The macro consists of: - CTRL-A - set mark - CTRL-F until you get to the start of the field after Call: - CTRL-W to delete the selected text - CTRL-N to go to the start of the next line After the macro is defined, there is a pause the next (first) time it's used (C-x C-e). It's speedy after that. You mean 'C-x e', not 'C-x C-e', right? I just inserted several lines like # New Exception Call: PD0TEST/J into the *scratch* buffer and defined your keyboard macro. I didn't notice any delay the first time I ran it. Might there be some other conditions necessary to reproduce the problem? Is the mode of the buffer relevant? Can you reproduce the problem starting from 'emacs -Q'? Ken -- 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
Re: [PATCH] Cygwin: Make native clipboard layout same for 32- and 64-bit
On 10/23/2021 1:35 AM, Mark Geisert wrote: Corinna Vinschen wrote: Just to close this up prior to the 3.3.0 release... Given we never actually strived for 32<->64 bit interoperability, it's hard to argue why this should be different for the clipboard stuff. Running 32 and 64 bit Cygwin versions in parallel doesn't actually make much sense for most people anyway, unless they explicitely develop for 32 and 64 bit systems under Cygwin. From a productivity point of view there's no good reason to run more than one arch. So I agree with Ken here. It's probably not worth the trouble. Sorry, I've been sidetracked for a bit. I can agree with Ken too. The only circumstance I could think of where multiple internal format support might be useful (to non-developers) was some user hanging on to an older Cygwin because it was needed to support something else (s/w or h/w) old and non-upgradeable. Doesn't seem very likely at this point. I'll try to get the v2 patch out over this weekend. Same end-result for same environments as the v1 patch, but incorporating all the comments I received. I think Corinna was saying that the whole idea of making the 32-bit and 64-bit clipboards interoperable is not worth the trouble. To that end, does Jon's suggestion of /usr/include/sys/cygwin.h seem like the best location to define struct cygcb_t for use by both Cygwin and cygutils package? Thanks much, ..mark
Re: Apache Fork Errors - Found on Windows Server 2019
On 10/18/2021 9:43 PM, OwN-3m-All via Cygwin wrote: I upgraded both libharfbuzz0 and libfreetype6 to the latest version again, and the issues are back. I tested these previous versions for both, and they work: libharfbuzz0 2.7.4-1 and 2.8.1-1 work libfreetype6 2.10.4-1 and 2.10.4-2 work The latest versions of these libs need to be reverted or properly fixed. The new packages (using the previous build method, with no circular dependency) are now available. Please test. Ken -- 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
[ANNOUNCEMENT] harfbuzz 2.9.0-2
The following packages have been uploaded to the Cygwin distribution: * harfbuzz-2.9.0-2 * libharfbuzz0-2.9.0-2 * libharfbuzz-devel-2.9.0-2 * libharfbuzz-gobject0-2.9.0-2 * libharfbuzz-gobject-devel-2.9.0-2 * libharfbuzz-subset0-2.9.0-2 * libharfbuzz-subset-devel-2.9.0-2 * libharfbuzz-icu0-2.9.0-2 * libharfbuzz-icu-devel-2.9.0-2 * girepository-HarfBuzz0.0-2.9.0-2 HarfBuzz is an OpenType text shaping engine. This is a rebuild of the 2.9.0-1 packages, without the circular dependency between harfbuzz and freetype2 that was introduced in 2.9.0-1. That circular dependency apparently caused the fork problems reported here: https://cygwin.com/pipermail/cygwin/2021-October/249610.html Ken Brown Cygwin's harfbuzz maintainer -- 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
[ANNOUNCEMENT] freetype2 2.11.0-2
The following packages have been uploaded to the Cygwin distribution: * freetype2-demos-2.11.0-2 * libfreetype6-2.11.0-2 * libfreetype-devel-2.11.0-2 * libfreetype-doc-2.11.0-2 FreeType 2 is a software font engine that is designed to be small, efficient, and highly customizable while capable of producing high-quality output (glyph images). This is a rebuild of the 2.11.0-1 packages, without the circular dependency between harfbuzz and freetype2 that was introduced in 2.11.0-1. That circular dependency apparently caused the fork problems reported here: https://cygwin.com/pipermail/cygwin/2021-October/249610.html Ken Brown Cygwin's FreeType2 maintainer -- 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
harfbuzz 2.9.0-2
The following packages have been uploaded to the Cygwin distribution: * harfbuzz-2.9.0-2 * libharfbuzz0-2.9.0-2 * libharfbuzz-devel-2.9.0-2 * libharfbuzz-gobject0-2.9.0-2 * libharfbuzz-gobject-devel-2.9.0-2 * libharfbuzz-subset0-2.9.0-2 * libharfbuzz-subset-devel-2.9.0-2 * libharfbuzz-icu0-2.9.0-2 * libharfbuzz-icu-devel-2.9.0-2 * girepository-HarfBuzz0.0-2.9.0-2 HarfBuzz is an OpenType text shaping engine. This is a rebuild of the 2.9.0-1 packages, without the circular dependency between harfbuzz and freetype2 that was introduced in 2.9.0-1. That circular dependency apparently caused the fork problems reported here: https://cygwin.com/pipermail/cygwin/2021-October/249610.html Ken Brown Cygwin's harfbuzz maintainer
freetype2 2.11.0-2
The following packages have been uploaded to the Cygwin distribution: * freetype2-demos-2.11.0-2 * libfreetype6-2.11.0-2 * libfreetype-devel-2.11.0-2 * libfreetype-doc-2.11.0-2 FreeType 2 is a software font engine that is designed to be small, efficient, and highly customizable while capable of producing high-quality output (glyph images). This is a rebuild of the 2.11.0-1 packages, without the circular dependency between harfbuzz and freetype2 that was introduced in 2.11.0-1. That circular dependency apparently caused the fork problems reported here: https://cygwin.com/pipermail/cygwin/2021-October/249610.html Ken Brown Cygwin's FreeType2 maintainer
Re: A Bug related to ImageTk in Python on Cygwin
On 10/19/2021 6:11 AM, Friedrich Romstedt via Cygwin wrote: Hi, Some months ago (in August 2021) I tried using ImageTk in Python on Cygwin and stumbled over a dysfunction. To help tracking down the issue I wrote up an HTML document and uploaded it to https://github.com/friedrichromstedt/bughunting-02. There is a minimal Test Case included in this github repo. I updated my whole Cygwin installation just this moment and found the behaviour unchanged with respect to what I've observed that time. Any pointer would be very much appreciated. This is a long shot, but I see that you use harfbuzz and freetype2. An issue was just observed with the latest builds of those two packages: https://cygwin.com/pipermail/cygwin/2021-October/249610.html I'm in the process of rebuilding them. Please try again once the rebuilds are announced (probably later today). Ken -- 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
Re: Apache Fork Errors - Found on Windows Server 2019
On 10/18/2021 4:43 PM, OwN-3m-All via Cygwin wrote: Since those are the two DLLs that are causing a problem for you, maybe that circular dependency doesn't work well on Cygwin for some reason. Please try downgrading to the previous versions of harfbuzz and freetype2 and see if that fixes the problem. That did fix the problem! I downgraded both and restarted, and now apache and php works again. Just to double check, could you upgrade harfbuzz and freetype2 again and see if the problem comes back? Make sure that there are no Cygwin processes running and that the _autorebase postinstall script completes successfully. (You can check /var/log/setup.log.full for rebase messages.) Can that change be reverted or fixed so that it doesn't happen on future installs? Yes, I'll revert that change if you can confirm as above that this really is the problem. Ken -- 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
Re: cat fifo hang [Re: [ANNOUNCEMENT] cygwin 3.3.0-0.2.6c1f49f83fde (TEST)]
On 10/17/2021 4:52 PM, Chris Roehrig wrote: Here's a script that pretty reliably hangs cat after some iterations. [...] Thanks! I can reproduce the hang. I'll look into it. Ken -- 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
Re: [ANNOUNCEMENT] cygwin 3.3.0-0.2.6c1f49f83fde (TEST)
On 10/16/2021 1:42 PM, Chris Roehrig wrote: On Mon Sep 27 2021, at 7:26 AM, Ken Brown via Cygwin wrote: On 9/26/2021 8:57 PM, Chris Roehrig wrote: I have installed this (completely this time) and have encountered no issues with it. I'm getting full gigabit speeds with my rsync transfers. Looks great! Thanks for testing. I've encountered a crash that might be related. I had previously been having occasional crashes/hangs of cat.exe over the years, but this is the first time I've ever gotten an error message: cygwin error: 0 [fifo_reader] cat 11398 C:\cygwin\bin\cat.exe: *** fatal error - Can't add a client handler, Win32 error 123 This isn't a crash in the usual sense. It's the Cygwin fifo code issuing a fatal error because an attempt to create a new Windows pipe instance failed. And it's in code that's been around for a while, so it's not related to the new pipe implementation. cat here is reading from a fifo created with mkfifo. I've only encountered it once (out of daily runs over the last couple weeks) and don't know how to replicate it. Possibly a race?Looks like my script has tried to mitigate this with a sleep 1 between the mkfifo and the fork: cat < $fifo & The sleep shouldn't be necessary. If it is, there's a bug in the fifo code. Can you remove the sleep and see what happens? It would be great if that made it possible to replicate the problem. Ken -- 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
Re: Apache Fork Errors - Found on Windows Server 2019
On 10/16/2021 9:49 PM, OwN-3m-All via Cygwin wrote: Hopefully I can strace at some point soon and get back to you with the results. I have multiple confirmed reports from other people that this no longer works though. And again, I tried it on three different fresh installs of different Windows operating systems (with no bloatware or BLODA), and all of them had the same issue. I have one other thought. There was a recent packaging change in harfbuzz and freetype2 that introduced a circular dependency between the two: https://cygwin.com/pipermail/cygwin/2021-September/249316.html https://cygwin.com/pipermail/cygwin/2021-September/249317.html Since those are the two DLLs that are causing a problem for you, maybe that circular dependency doesn't work well on Cygwin for some reason. Please try downgrading to the previous versions of harfbuzz and freetype2 and see if that fixes the problem. Ken -- 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
Re: Apache Fork Errors - Found on Windows Server 2019
On 10/15/2021 4:04 PM, OwN-3m-All via Cygwin wrote: Downgrading (choosing lower versions) httpd and httpd-mod_php7 didn't help. Same issue. It appears to be something cygwin specific and not package related? I don't know... Running the httpd command under strace might provide a clue. See if you see any unexpected DLLs being loaded. Ken -- 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
Re: emacs 28.0.60-1.f7e6c199bf (TEST)
On 10/14/2021 10:38 AM, Jim Reisert AD1C wrote: I have noticed one slight performance issue, which may not be related to Cygwin at all. After creating a keyboard macro, the first time the macro is used/called (^x^e), it does not start right away. Subsequent uses are as fast as expected. Could some sort of run-time compilation going on in the background before the keyboard macro executes the first time? As I said, this may not be related to Cygwin at all. This is mentioned in the announcement for emacs 28.0.60-1.f7e6c199bf (TEST) The first few times you run Emacs, it might seem slow to start. This is because it is compiling the elisp libraries that are needed for your init file (usually .emacs). For the same reason, you might see occasional pauses the first time you use a command. But otherwise you should see a noticeable speed-up of Emacs. I'm not talking about startup or commands. I'm talking about keyboard macros which are not mentioned in the paragraph above. I've already experienced those symptoms described. I've defined a few keyboard macros and haven't noticed any delay, but they were very short. Do you have a reproducible recipe? Ken -- 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
[ANNOUNCEMENT] ghostscript 9.55.0-1 (TEST)
The following packages have been uploaded to the Cygwin distribution as test releases: * ghostscript-9.55.0-1 * libgs9-9.55.0-1 * libgs-devel-9.55.0-1 GNU Ghostscript is a PostScript interpreter capable of converting PS files into a number of printer output formats. Ghostscript can also render PS files into a number of graphics file formats. This is an update to the latest upstream release. See http://www.ghostscript.com/doc/9.55.0/News.htm for a summary of the changes since the previous release. Ken Brown Cygwin's Ghostscript maintainer -- 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
ghostscript 9.55.0-1 (TEST)
The following packages have been uploaded to the Cygwin distribution as test releases: * ghostscript-9.55.0-1 * libgs9-9.55.0-1 * libgs-devel-9.55.0-1 GNU Ghostscript is a PostScript interpreter capable of converting PS files into a number of printer output formats. Ghostscript can also render PS files into a number of graphics file formats. This is an update to the latest upstream release. See http://www.ghostscript.com/doc/9.55.0/News.htm for a summary of the changes since the previous release. Ken Brown Cygwin's Ghostscript maintainer
Re: [PATCH] Cygwin: Make native clipboard layout same for 32- and 64-bit
On 10/11/2021 2:13 AM, Mark Geisert wrote: It's just that after submitting the patch I realized that, if we really are going to support both Cygwin archs (x86_64 and i686), there is still the issue of different cygcb_t layouts between Cygwin versions being ignored. Specifically, the fhandler_clipboard::fstat routine can't tell which Cygwin environment has set the clipboard contents. My original patch takes care of 32-bit and 64-bit, providing both are running Cygwin >= 3.3.0 (presumably). What if it was a different version (pre 3.3.0) that set the contents? I wonder if this is worth the trouble. Right now we have a problem in which data written to /dev/clipboard in one arch can't be read in the other arch. The fix will appear in Cygwin 3.3.0. Do we really have to try to make the fix apply retroactively in case the user updates one arch but not the other? Ken
Re: [PATCH] Cygwin: pty: Fix handle leak regarding attach_mutex.
On 10/9/2021 8:49 PM, Takashi Yano wrote:
- If the process having master pty opened is forked, attach_mutex
fails to be closed when master is closed. This patch fixes the
issue.
---
winsup/cygwin/fhandler_console.cc | 2 +-
winsup/cygwin/fhandler_tty.cc | 6 +++---
2 files changed, 4 insertions(+), 4 deletions(-)
diff --git a/winsup/cygwin/fhandler_console.cc
b/winsup/cygwin/fhandler_console.cc
index ee862b17d..aee5e8284 100644
--- a/winsup/cygwin/fhandler_console.cc
+++ b/winsup/cygwin/fhandler_console.cc
@@ -57,7 +57,7 @@ fhandler_console::console_state NO_COPY
*fhandler_console::shared_console_info;
bool NO_COPY fhandler_console::invisible_console;
/* Mutex for AttachConsole()/FreeConsole() in fhandler_tty.cc */
-HANDLE NO_COPY attach_mutex;
+HANDLE attach_mutex;
static inline void
acquire_attach_mutex (DWORD t)
diff --git a/winsup/cygwin/fhandler_tty.cc b/winsup/cygwin/fhandler_tty.cc
index 823dabf73..f523dafed 100644
--- a/winsup/cygwin/fhandler_tty.cc
+++ b/winsup/cygwin/fhandler_tty.cc
@@ -57,7 +57,7 @@ struct pipe_reply {
};
extern HANDLE attach_mutex; /* Defined in fhandler_console.cc */
-static LONG NO_COPY master_cnt = 0;
+static LONG master_cnt = 0;
inline static bool pcon_pid_alive (DWORD pid);
@@ -2042,10 +2042,10 @@ fhandler_pty_master::close ()
}
release_output_mutex ();
master_fwd_thread->terminate_thread ();
- if (InterlockedDecrement (_cnt) == 0)
- CloseHandle (attach_mutex);
}
}
+ if (InterlockedDecrement (_cnt) == 0)
+CloseHandle (attach_mutex);
/* Check if the last master handle has been closed. If so, set
input_available_event to wake up potentially waiting slaves. */
Pushed. Thanks.
Ken
Re: [PATCH] Cygwin: Make native clipboard layout same for 32- and 64-bit
On 10/9/2021 10:29 AM, Jon Turney wrote:
On 07/10/2021 06:22, Mark Geisert wrote:
> The cygutils package has two programs, putclip and getclip, that also
> depend on the layout of the cygcb_t. At present they have duplicate
> defs of struct cygcb_t defined here as no Cygwin header provides it.
This struct should maybe be in sys/cygwin.h or similar, if it's expected to be
used in user-space as well.
Good idea.
On 09/10/2021 15:19, Ken Brown wrote:
On 10/8/2021 5:52 AM, Takashi Yano wrote:
How about simply just:
diff --git a/winsup/cygwin/fhandler_clipboard.cc
b/winsup/cygwin/fhandler_clipboard.cc
index ccdb295f3..d822f4fc4 100644
--- a/winsup/cygwin/fhandler_clipboard.cc
+++ b/winsup/cygwin/fhandler_clipboard.cc
@@ -28,9 +28,10 @@ static const WCHAR *CYGWIN_NATIVE =
L"CYGWIN_NATIVE_CLIPBOARD";
typedef struct
{
- timestruc_t timestamp;
- size_t len;
- char data[1];
+ uint64_t tv_sec;
+ uint64_t tv_nsec;
+ uint64_t len;
+ char data[1];
} cygcb_t;
The only problem with this is that it might leave readers scratching their
heads unless they look at the commit that introduced this. What
I think the solution to that is a "comment" like "we don't use 'struct timespec'
here as it's different size on different arches and that causes problem XYZ".
And the same for size_t.
Ken
Re: [PATCH] Cygwin: Make native clipboard layout same for 32- and 64-bit
On 10/8/2021 5:52 AM, Takashi Yano wrote:
How about simply just:
diff --git a/winsup/cygwin/fhandler_clipboard.cc
b/winsup/cygwin/fhandler_clipboard.cc
index ccdb295f3..d822f4fc4 100644
--- a/winsup/cygwin/fhandler_clipboard.cc
+++ b/winsup/cygwin/fhandler_clipboard.cc
@@ -28,9 +28,10 @@ static const WCHAR *CYGWIN_NATIVE =
L"CYGWIN_NATIVE_CLIPBOARD";
typedef struct
{
- timestruc_t timestamp;
- size_t len;
- char data[1];
+ uint64_t tv_sec;
+ uint64_t tv_nsec;
+ uint64_t len;
+ char data[1];
} cygcb_t;
The only problem with this is that it might leave readers scratching their heads
unless they look at the commit that introduced this. What about something like
the following, in which the code speaks for itself:
diff --git a/winsup/cygwin/fhandler_clipboard.cc
b/winsup/cygwin/fhandler_clipboard.cc
index ccdb295f3..028c00f1e 100644
--- a/winsup/cygwin/fhandler_clipboard.cc
+++ b/winsup/cygwin/fhandler_clipboard.cc
@@ -26,12 +26,26 @@ details. */
static const WCHAR *CYGWIN_NATIVE = L"CYGWIN_NATIVE_CLIPBOARD";
+#ifdef __x86_64__
typedef struct
{
timestruc_t timestamp;
size_t len;
char data[1];
} cygcb_t;
+#else
+/* Use same layout. */
+typedef struct
+{
+ struct
+ {
+int64_t tv_sec;
+int64_t tv_nsec;
+ }timestamp;
+ uint64_t len;
+ char data[1];
+} cygcb_t;
+#endif
fhandler_dev_clipboard::fhandler_dev_clipboard ()
: fhandler_base (), pos (0), membuffer (NULL), msize (0)
@@ -74,7 +88,14 @@ fhandler_dev_clipboard::set_clipboard (const void *buf,
size_t len)
}
clipbuf = (cygcb_t *) GlobalLock (hmem);
+#ifdef __x86_64__
clock_gettime (CLOCK_REALTIME, >timestamp);
+#else
+ timestruc_t ts;
+ clock_gettime (CLOCK_REALTIME, );
+ clipbuf->timestamp->tv_sec = ts.tv_sec;
+ clipbuf->timestamp->tv_nsec = ts.tv_nsec;
+#endif
clipbuf->len = len;
memcpy (clipbuf->data, buf, len);
@@ -179,7 +200,14 @@ fhandler_dev_clipboard::fstat (struct stat *buf)
&& (hglb = GetClipboardData (format))
&& (clipbuf = (cygcb_t *) GlobalLock (hglb)))
{
+#ifdef __x86_64__
buf->st_atim = buf->st_mtim = clipbuf->timestamp;
+#else
+ timestruc_t ts;
+ ts.tv_sec = clipbuf->timestamp->tv_sec;
+ ts.tv_nsec = clipbuf->timestamp->tv_nsec;
+ buf->st_atim = buf->st_mtim = ts;
+#endif
buf->st_size = clipbuf->len;
GlobalUnlock (hglb);
}
Ken
Re: [PATCH] Cygwin: pty: Fix master closing error regarding attach_mutex.
On 10/8/2021 12:28 PM, Takashi Yano wrote:
- If two or more pty masters are opened in a process, closing master
causes error when closing attach_mutex. This patch fixes the issue.
Addresses:
https://cygwin.com/pipermail/cygwin-developers/2021-October/012418.html
---
winsup/cygwin/fhandler_tty.cc | 7 +--
winsup/cygwin/release/3.3.0 | 3 +++
2 files changed, 8 insertions(+), 2 deletions(-)
diff --git a/winsup/cygwin/fhandler_tty.cc b/winsup/cygwin/fhandler_tty.cc
index 05fe5348a..823dabf73 100644
--- a/winsup/cygwin/fhandler_tty.cc
+++ b/winsup/cygwin/fhandler_tty.cc
@@ -57,6 +57,7 @@ struct pipe_reply {
};
extern HANDLE attach_mutex; /* Defined in fhandler_console.cc */
+static LONG NO_COPY master_cnt = 0;
inline static bool pcon_pid_alive (DWORD pid);
@@ -2041,7 +2042,8 @@ fhandler_pty_master::close ()
}
release_output_mutex ();
master_fwd_thread->terminate_thread ();
- CloseHandle (attach_mutex);
+ if (InterlockedDecrement (_cnt) == 0)
+ CloseHandle (attach_mutex);
}
}
@@ -2876,7 +2878,8 @@ fhandler_pty_master::setup ()
if (!(pcon_mutex = CreateMutex (, FALSE, buf)))
goto err;
- attach_mutex = CreateMutex (, FALSE, NULL);
+ if (InterlockedIncrement (_cnt) == 1)
+attach_mutex = CreateMutex (, FALSE, NULL);
/* Create master control pipe which allows the master to duplicate
the pty pipe handles to processes which deserve it. */
diff --git a/winsup/cygwin/release/3.3.0 b/winsup/cygwin/release/3.3.0
index 2f7340ac5..2df81a4ae 100644
--- a/winsup/cygwin/release/3.3.0
+++ b/winsup/cygwin/release/3.3.0
@@ -71,3 +71,6 @@ Bug Fixes
in ps(1) output.
Addresses: https://cygwin.com/pipermail/cygwin/2021-July/248998.html
https://cygwin.com/pipermail/cygwin/2021-August/249124.html
+
+- Fix pty master closing error regarding attach_mutex.
+ Addresses:
https://cygwin.com/pipermail/cygwin-developers/2021-October/012418.html
Pushed. Thanks.
Ken
Re: GNU Emacs 28.0.50 crash (emacs-w32)
On 10/7/2021 4:21 PM, Jim Reisert AD1C wrote: I'm about to announce a new test release that tries to work around the problem in a different way. I'd be interested in hearing how that works too. I updated Emacs and turned off "native-comp-async-query-on-exit". This time, there was no error report from emacs-w32, it just silently exited while the compilation was ongoing. I don't know if that was the desired outcome. Yes. All I did was to suppress the error report. It turns out that there was actually a Cygwin bug underlying this, which will be fixed in Cygwin 3.3.0: https://cygwin.com/pipermail/cygwin-developers/2021-October/012418.html So I'll be able to remove the workaround once Cygwin 3.3.0 is released. Ken -- 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
[ANNOUNCEMENT] emacs 28.0.60-1.f7e6c199bf (TEST)
The following packages have been uploaded to the Cygwin distribution as test releases: * emacs-28.0.60-1.f7e6c199bf * emacs-common-28.0.60-1.f7e6c199bf * emacs-X11-28.0.60-1.f7e6c199bf * emacs-w32-28.0.60-1.f7e6c199bf * emacs-lucid-28.0.60-1.f7e6c199bf Emacs is a powerful, customizable, self-documenting, modeless text editor. Emacs contains special code editing features, a scripting language (elisp), and the capability to read mail, news, and more without leaving the editor. This is a *very* preliminary pretest for emacs-28.1. The latter will include a major new feature, native compilation (explained below). The purpose of this test release is to help us figure out what changes will be needed (on both the Cygwin side and the Emacs side) to make native compilation work well on Cygwin. This test release includes an attempted workaround for the problem reported here with the previous test release: https://cygwin.com/pipermail/cygwin/2021-October/249575.html The test release is not recommended for 32-bit Cygwin. If you try it, you will almost certainly see fork errors while running emacs. Once we get native compilation working well on 64-bit Cygwin, we'll see what can be done for the 32-bit case. If you want to try this test release, please do the following: 1. Install the test release of the _autorebase package. 2. Create a file /var/lib/rebase/userpath.d/ with one line, which is the absolute path to ~/.emacs.d/eln-cache. For example, on my system I have: $ cat /var/lib/rebase/userpath.d/kbrown /home/kbrown/.emacs.d/eln-cache If more than one user will be using Emacs on your system, create a file like this for each user. Here is the promised explanation of native compilation: Many of the editing commands used in Emacs are defined in elisp libraries (*.el files). To make Emacs run faster, these libraries are usually compiled to architecture-independent *.elc files, containing "byte-code" representations of the functions in the original files. These byte-code functions are interpreted by the Emacs "byte-code interpreter" when they are called. Native compilation takes this one step further by using gcc to compile the elisp libraries to native shared libraries (like DLLs, but with an extension .eln instead of .dll). This results in a substantial speed-up of Emacs. Some of the .eln files are created at build time. These are installed in a subdirectory of /usr/lib/emacs//native-lisp. Others are created as needed and are stored by default in a subdirectory of ~/.emacs.d/eln-cache. (You can change this default, but then you also have to make the corresponding change to /var/lib/rebase/userpath.d/.) Final remarks: 1. The first few times you run Emacs, it might seem slow to start. This is because it is compiling the elisp libraries that are needed for your init file (usually .emacs). For the same reason, you might see occasional pauses the first time you use a command. But otherwise you should see a noticeable speed-up of Emacs. 2. To prevent fork failures, the .eln files need to be rebased occasionally, for the reasons explained here: https://cygwin.com/cygwin-ug-net/highlights.html#ov-hi-process-problems This is handled by the test release of _autorebase mentioned above every time you run setup (which you should do with no cygwin processes running). But it is not currently done when new .eln files are created. This is mostly a problem on 32-bit Cygwin and is not yet solved. The main purpose of this test release of Emacs is to find out if it is likely to be a problem in the 64-bit case. Ken Brown Cygwin's Emacs maintainer -- 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
emacs 28.0.60-1.f7e6c199bf (TEST)
The following packages have been uploaded to the Cygwin distribution as test releases: * emacs-28.0.60-1.f7e6c199bf * emacs-common-28.0.60-1.f7e6c199bf * emacs-X11-28.0.60-1.f7e6c199bf * emacs-w32-28.0.60-1.f7e6c199bf * emacs-lucid-28.0.60-1.f7e6c199bf Emacs is a powerful, customizable, self-documenting, modeless text editor. Emacs contains special code editing features, a scripting language (elisp), and the capability to read mail, news, and more without leaving the editor. This is a *very* preliminary pretest for emacs-28.1. The latter will include a major new feature, native compilation (explained below). The purpose of this test release is to help us figure out what changes will be needed (on both the Cygwin side and the Emacs side) to make native compilation work well on Cygwin. This test release includes an attempted workaround for the problem reported here with the previous test release: https://cygwin.com/pipermail/cygwin/2021-October/249575.html The test release is not recommended for 32-bit Cygwin. If you try it, you will almost certainly see fork errors while running emacs. Once we get native compilation working well on 64-bit Cygwin, we'll see what can be done for the 32-bit case. If you want to try this test release, please do the following: 1. Install the test release of the _autorebase package. 2. Create a file /var/lib/rebase/userpath.d/ with one line, which is the absolute path to ~/.emacs.d/eln-cache. For example, on my system I have: $ cat /var/lib/rebase/userpath.d/kbrown /home/kbrown/.emacs.d/eln-cache If more than one user will be using Emacs on your system, create a file like this for each user. Here is the promised explanation of native compilation: Many of the editing commands used in Emacs are defined in elisp libraries (*.el files). To make Emacs run faster, these libraries are usually compiled to architecture-independent *.elc files, containing "byte-code" representations of the functions in the original files. These byte-code functions are interpreted by the Emacs "byte-code interpreter" when they are called. Native compilation takes this one step further by using gcc to compile the elisp libraries to native shared libraries (like DLLs, but with an extension .eln instead of .dll). This results in a substantial speed-up of Emacs. Some of the .eln files are created at build time. These are installed in a subdirectory of /usr/lib/emacs//native-lisp. Others are created as needed and are stored by default in a subdirectory of ~/.emacs.d/eln-cache. (You can change this default, but then you also have to make the corresponding change to /var/lib/rebase/userpath.d/.) Final remarks: 1. The first few times you run Emacs, it might seem slow to start. This is because it is compiling the elisp libraries that are needed for your init file (usually .emacs). For the same reason, you might see occasional pauses the first time you use a command. But otherwise you should see a noticeable speed-up of Emacs. 2. To prevent fork failures, the .eln files need to be rebased occasionally, for the reasons explained here: https://cygwin.com/cygwin-ug-net/highlights.html#ov-hi-process-problems This is handled by the test release of _autorebase mentioned above every time you run setup (which you should do with no cygwin processes running). But it is not currently done when new .eln files are created. This is mostly a problem on 32-bit Cygwin and is not yet solved. The main purpose of this test release of Emacs is to find out if it is likely to be a problem in the 64-bit case. Ken Brown Cygwin's Emacs maintainer
Re: GNU Emacs 28.0.50 crash (emacs-w32)
On 10/7/2021 10:16 AM, Jim Reisert AD1C wrote: Could this be the following problem that I mentioned in the release announcement? Compilation is done asynchronously, with a log in a buffer called *Async-native-compile-log*. If you run emacs-w32 and exit while a compilation is in progress, you might see a dialog box saying that emacs has aborted and asking if you want to attach a debugger. Just say No. If this annoys you, check the compilation buffer before exiting, and wait for the "Compilation finished" message. I'll add one more thing that I didn't know when I wrote that: You can customize the variable native-comp-async-query-on-exit if you want to be warned that there are compilations in process when you exit. Sure, that could be the problem. I'll try the workaround. Thanks. Please report back. I'm about to announce a new test release that tries to work around the problem in a different way. I'd be interested in hearing how that works too. I do notice that there are separate compilation directories for emacs and emacs-w32. Is this necessary? Yes. Each build environment for emacs requires its own compiled libraries. Here "build environment" includes source files, system, and configuration options. In this case, the build of emacs-w32 used the configuration option "--with-w32" that wasn't used in the build of emacs-X11. Thanks very much for testing! Ken -- 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
Re: Question about 'provides' and emacs packaging
On 10/6/2021 4:22 PM, Jon Turney wrote: On 06/10/2021 17:23, Jon Turney wrote: On 06/10/2021 13:01, Ken Brown via Cygwin-apps wrote: This seems to work, with one caveat. Suppose package P requires feature f, and packages Q, R, S,... provide f. If the user selects P and one or more of Q, R, S,..., setup is happy. But if the user simply selects P, then setup/libsolv will choose among Q, R, S,... the one whose name is alphabetically first. In the emacs case, this would be emacs-lucid, which is a stupid default. The default ought to be emacs-nox. So I can make it work if I call that package emacs-basic instead of emacs-nox. Yeah, I think what's wanted here is for the solver to output a problem with the choices, rather than picking one. I'm not sure how to get it to do that. (Ofc, then we need some UI for picking problem solutions, rather than just always using the default) Thinking about this some more, that's probably not how it wants to work, since just installing emacs-common would then require user interaction to solve the problem, rather than just installing emacs-nox as well... Agreed. (and I'm not sure how we'd encode "emacs-basic" should be the default provider of "emacs-bin" as the input into the solver; presumably there'd by some scheme with weights attached to provide names to set the order rather than alphabetic) So all that's left is to fix that. This is discussed somewhat in [1], and it seems that having emacs-common suggest: or weak-dep: on emacs-nox would cause that to be the preferred provide:r by the solver (in the absence of other provide:ing packages being selected or installed) Yes, that sounds right... So I guess we'd need to add something like that to setup.ini and feed that data into the solver as well. ...but I'm not sure it's worth the trouble unless other package maintainers would also have a use for this. As far as emacs is concerned, I'm fine just changing "emacs-nox" to "emacs-basic" so that it's alphabetically first. Ken
Re: GNU Emacs 28.0.50 crash (emacs-w32)
On 10/6/2021 11:38 AM, Ken Brown via Cygwin wrote: On 10/6/2021 10:22 AM, Jim Reisert AD1C wrote: The test release of GNU Emacs 28.0.50 crashed on me when using emacs-w32. I can repeat this every time. I attached the trace and stackdump. Windows 11 Pro 64-bit Take Command 27.01.24 x64 Opened a text file using emacs-w32 Ctrl-X Ctrl-C to exit Exit Emacs I did not make any changes to the text file Could this be the following problem that I mentioned in the release announcement? Compilation is done asynchronously, with a log in a buffer called *Async-native-compile-log*. If you run emacs-w32 and exit while a compilation is in progress, you might see a dialog box saying that emacs has aborted and asking if you want to attach a debugger. Just say No. If this annoys you, check the compilation buffer before exiting, and wait for the "Compilation finished" message. I'll add one more thing that I didn't know when I wrote that: You can customize the variable native-comp-async-query-on-exit if you want to be warned that there are compilations in process when you exit. Having said that, I'll still try to track down the cause of the crash. Ken -- 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
Re: GNU Emacs 28.0.50 crash (emacs-w32)
On 10/6/2021 10:22 AM, Jim Reisert AD1C wrote: The test release of GNU Emacs 28.0.50 crashed on me when using emacs-w32. I can repeat this every time. I attached the trace and stackdump. Windows 11 Pro 64-bit Take Command 27.01.24 x64 Opened a text file using emacs-w32 Ctrl-X Ctrl-C to exit Exit Emacs I did not make any changes to the text file Could this be the following problem that I mentioned in the release announcement? Compilation is done asynchronously, with a log in a buffer called *Async-native-compile-log*. If you run emacs-w32 and exit while a compilation is in progress, you might see a dialog box saying that emacs has aborted and asking if you want to attach a debugger. Just say No. If this annoys you, check the compilation buffer before exiting, and wait for the "Compilation finished" message. I'll add one more thing that I didn't know when I wrote that: You can customize the variable native-comp-async-query-on-exit if you want to be warned that there are compilations in process when you exit. Ken -- 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
Re: Question about 'provides' and emacs packaging
On 10/5/2021 2:24 PM, Achim Gratz wrote: Ken Brown via Cygwin-apps writes: There are currently five emacs packages: emacs-common, emacs, emacs-X11, emacs-w32, and emacs-lucid. The first includes things that are needed by each of the other four, and those four each include an emacs binary. The binary in the emacs package is /usr/bin/emacs-nox.exe. The other packages contain /usr/bin/emacs-X11.exe, and so on. This way of naming the packages doesn't really reflect the contents of the emacs package. It also means that anyone who installs emacs gets emacs-nox.exe, even if they plan to use one of the other three binaries. I would rather rename the current emacs-common package to emacs and the current emacs package to emacs-nox. But then the new emacs would have to have a way of requiring the installation of at least one of emacs-nox, emacs-X11, emacs-w32, or emacs-lucid. Is there any way to do this with our current setup machinery? I don't think we have the transaction capability that would be necessary to specify that the meaning of an already existing package name (two, actually) changes in this manner. You might have to use new package names and place the appropriate obsoletions w.r.t. old names instead. My idea three years ago was to have the new emacs package require a "feature" called, for instance, emacs-bin, and then have each of emacs-nox, emacs-X11, emacs-w32, emacs-lucid "provide" that feature. I have no idea if multiple packages can provide the same feature. It's worth trying if it does what you want (you must pick at least one of those). This seems to work, with one caveat. Suppose package P requires feature f, and packages Q, R, S,... provide f. If the user selects P and one or more of Q, R, S,..., setup is happy. But if the user simply selects P, then setup/libsolv will choose among Q, R, S,... the one whose name is alphabetically first. In the emacs case, this would be emacs-lucid, which is a stupid default. The default ought to be emacs-nox. So I can make it work if I call that package emacs-basic instead of emacs-nox. I've only tested setup so far, not calm. Jon, if you're reading this, does calm allow 'requires' and 'provides' to contain arbitrary names that are not package names? Ken
Re: Question about 'provides' and emacs packaging
On 10/5/2021 12:58 PM, Brian Inglis wrote: On 2021-10-05 09:51, Ken Brown via Cygwin-apps wrote: I asked this question several years ago (https://cygwin.com/pipermail/cygwin-apps/2018-October/039451.html), but I'm repeating it, in a more specific form, in the hope that setup has progressed to the point where I get a different answer. There are currently five emacs packages: emacs-common, emacs, emacs-X11, emacs-w32, and emacs-lucid. The first includes things that are needed by each of the other four, and those four each include an emacs binary. The binary in the emacs package is /usr/bin/emacs-nox.exe. The other packages contain /usr/bin/emacs-X11.exe, and so on. This way of naming the packages doesn't really reflect the contents of the emacs package. It also means that anyone who installs emacs gets emacs-nox.exe, even if they plan to use one of the other three binaries. I would rather rename the current emacs-common package to emacs and the current emacs package to emacs-nox. But then the new emacs would have to have a way of requiring the installation of at least one of emacs-nox, emacs-X11, emacs-w32, or emacs-lucid. Is there any way to do this with our current setup machinery? My idea three years ago was to have the new emacs package require a "feature" called, for instance, emacs-bin, and then have each of emacs-nox, emacs-X11, emacs-w32, emacs-lucid "provide" that feature. This is what Fedora does. Achim didn't think this was feasible without major changes in setup. Is that still the case? If so, can anyone think of another way to accomplish what I want? Hi Ken, Achim recently restructured gnuplot; I used to install gnuplot, gnuplot-base now obsoletes that, and that is all I have installed; alternatives handles the priorities if different packages provide gnuplot: https://cygwin.com/git-cygwin-packages/?p=git/cygwin-packages/gnuplot.git gnuplot-base depends2: cygwin, libcairo2, libcerf1, libgd3, libglib2.0_0, liblua5.3, libpango1.0_0, libreadline7 gnuplot-X11 depends2: cygwin, gnuplot-base, libX11_6, ... gnuplot-qt5 depends2: cygwin, gnuplot-X11, libQt5Core5, libQt5Gui5, libQt5Svg5, libgcc1, ... libstdc++6 gnuplot-wx depends2: cygwin, gnuplot-X11, libgcc1, ... libgtk3_0, libstdc++6, libwx_baseu3.0_0, libwx_gtk3u3.0_0 This is very similar to what I currently have in emacs, although with better names. gnuplot-base is comparable to emacs-common+emacs. It doesn't achieve what I was asking for. But if what I was asking for isn't possible, I might still do some renaming, to make the contents clearer. Thanks. Ken
