pthread_sigqueue(): First parameter is incompatible with glibc
Cygwin /usr/include/pthread.h:
int pthread_sigqueue (pthread_t *, int, const union sigval);
Linux /usr/include/x86_64-linux-gnu/bits/sigthread.h:
extern int pthread_sigqueue (pthread_t __threadid, int __signo,
const union sigval __value) __THROW;
It is apparently the case since the very first related patch:
https://sourceware.org/pipermail/cygwin-patches/2012q1/007565.html
RCS file: /cvs/src/src/winsup/cygwin/thread.cc,v
...
+extern "C" int
+pthread_sigqueue (pthread_t *thread, int sig, const union sigval value)
+{
...
Found by checking usages of __CYGWIN__ in stress-ng source (builds OOTB,
maybe ITP):
https://github.com/ColinIanKing/stress-ng/commit/17c7a0d
--
Regards,
Christian
--
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
readdir() returns inaccessible name if file was created with invalid UTF-8
If a file name contains an invalid (truncated) UTF-8 sequence, open() does not refuse to create the file. Later readdir() returns a different name which could not be used to access the file. Testcase with U+1F321 (Thermometer): $ uname -r 3.5.4-1.x86_64 $ printf $'\U0001F321' | od -A none -t x1 f0 9f 8c a1 $ touch 'file1-'$'\xf0\x9f\x8c\xa1''.ext' $ touch 'file2-'$'\xf0\x9f\x8c''.ext' $ touch 'file3-'$'\xf0\x9f\x8c' $ ls -1 ls: cannot access 'file2-.?ext': No such file or directory ls: cannot access 'file3-': No such file or directory 'file1-'$'\360\237\214\241''.ext' file2-.?ext file3- Name mapping according to "fhandler_disk_file::readdir" strace lines: "file1-\xF0\x9F\x8C\xA1.ext" -(open)-> L"file1-\xD83C\xDF21.ext" -(readdir)-> "file1-\xF0\x9F\x8C\xA1.ext" "file2-\xF0\x9f\x8C.ext" -(open)-> L"file2-\xD83C\xF02Eext" -(readdir)-> "file2-.\xE1\x9E\xB3ext" "file3-\xF0\x9F\x8C" -(open)-> L"file3-\xD83C\xF000" -(readdir)-> "file3-" Issue found because 'stress-ng --filename ...' could not cleanup its temp directory. -- Regards, Christian -- 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: readdir() returns inaccessible name if file was created with invalid UTF-8
Thomas Wolff via Cygwin wrote: Am 15.09.2024 um 20:15 schrieb Thomas Wolff via Cygwin: Am 15.09.2024 um 19:47 schrieb Christian Franke via Cygwin: If a file name contains an invalid (truncated) UTF-8 sequence, open() does not refuse to create the file. Later readdir() returns a different name which could not be used to access the file. Testcase with U+1F321 (Thermometer): $ uname -r 3.5.4-1.x86_64 $ printf $'\U0001F321' | od -A none -t x1 f0 9f 8c a1 $ touch 'file1-'$'\xf0\x9f\x8c\xa1''.ext' $ touch 'file2-'$'\xf0\x9f\x8c''.ext' $ touch 'file3-'$'\xf0\x9f\x8c' $ ls -1 ls: cannot access 'file2-.?ext': No such file or directory ls: cannot access 'file3-': No such file or directory 'file1-'$'\360\237\214\241''.ext' file2-.?ext file3- I don't reproduce this. Yes, sorry, the above 'ls' was actually aliased to 'ls --color=auto' which needs to call stat(). Plain 'ls' does not, so the errors do not occur then. While the file name gets mangled, all resulting file names are valid and listed: In file2 the sequence is turned into U+17B3 but exchanged with the dot. In file3 the same sequence is just dropped. $ ls -1|cat file1-🌡.ext file2-.ឳext file3- However, ls file2* fails, as does ls *. On the other hand, ls file3- fails too, so some mapping error occurs internally. Also, the files cannot be deleted from cygwin (need to use cmd). 'rm' using the original names works for file2-..., but not for file3-... $ rm -v 'file2-'$'\xf0\x9f\x8c''.ext' removed 'file2-'$'\360\237\214''.ext' $ rm -v 'file3-'$'\xf0\x9f\x8c' rm: cannot remove 'file3-'$'\360\237\214': No such file or directory -- 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: readdir() returns inaccessible name if file was created with invalid UTF-8
Christian Franke via Cygwin wrote: Thomas Wolff via Cygwin wrote: Am 15.09.2024 um 20:15 schrieb Thomas Wolff via Cygwin: Am 15.09.2024 um 19:47 schrieb Christian Franke via Cygwin: If a file name contains an invalid (truncated) UTF-8 sequence, open() does not refuse to create the file. Later readdir() returns a different name which could not be used to access the file. Testcase with U+1F321 (Thermometer): $ uname -r 3.5.4-1.x86_64 $ printf $'\U0001F321' | od -A none -t x1 f0 9f 8c a1 $ touch 'file1-'$'\xf0\x9f\x8c\xa1''.ext' $ touch 'file2-'$'\xf0\x9f\x8c''.ext' $ touch 'file3-'$'\xf0\x9f\x8c' $ ls -1 ls: cannot access 'file2-.?ext': No such file or directory ls: cannot access 'file3-': No such file or directory 'file1-'$'\360\237\214\241''.ext' file2-.?ext file3- I don't reproduce this. Yes, sorry, the above 'ls' was actually aliased to 'ls --color=auto' which needs to call stat(). Plain 'ls' does not, so the errors do not occur then. While the file name gets mangled, all resulting file names are valid and listed: In file2 the sequence is turned into U+17B3 but exchanged with the dot. In file3 the same sequence is just dropped. $ ls -1|cat file1-🌡.ext file2-.ឳext file3- However, ls file2* fails, as does ls *. On the other hand, ls file3- fails too, so some mapping error occurs internally. Also, the files cannot be deleted from cygwin (need to use cmd). 'rm' using the original names works for file2-..., but not for file3-... $ rm -v 'file2-'$'\xf0\x9f\x8c''.ext' removed 'file2-'$'\360\237\214''.ext' $ rm -v 'file3-'$'\xf0\x9f\x8c' rm: cannot remove 'file3-'$'\360\237\214': No such file or directory Further tests suggest that the problem only occurs with: - incomplete 4 byte UTF-8 sequences (Unicode above 16 bit) - complete but invalid 3 byte UTF-8 sequences which encode the UTF-16 'high surrogate' range (0xD800..0xDBFF). -- 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: Cygwin setup reporter as malware
Dan Harkless via Cygwin wrote: On 12/9/2022 3:39 AM, Oskar Skog via Cygwin wrote: On 2022-12-07 23:54, Dan Harkless via Cygwin wrote: > No. It's normal and common for software like Cygwin, which has the > power to be used maliciously (as opposed to, say, a Minesweeper game or > something), to have false positives on VirusTotal for a handful of > vendors. I've never heard of SecureAge or Trapmine (hmm, maybe it > *would* flag Minesweeper...), and I'm pretty well educated in the > anti-malware space, so if it were me, I'd just ignore those false > positives and pay attention to the credible AV software results (and the > Community Score). You may have thought you were joking, but... https://www.virustotal.com/gui/file/bcff89311d792f6428468e813ac6929a346a979f907071c302f418d128eaaf41 This is not just *a* minesweeper game, it is *the* minesweeper game from Window XP. LOL! You're right, I'd never heard about that, and was just using Minesweeper as an obviously safe example program. And whaddaya know, it's SecureAge and Trapmine (oy!) that "flag" it. I guess the lesson is to always ignore SecureAge and Trapmine results on VirusTotal, and the OP should suggest VirusTotal drop those two from their AV software suite. Thanks for the amusing link, Oskar. Amusing, indeed. This was less amusing: After I released this file Dec 30, 2018, it scored 7/67 and then 13/70 a few hours later, including well-known AV vendors: https://www.virustotal.com/gui/file/bf0416c2e214c6323fdf1af8b853f761c846760f02950453c8a5bb276c961fbe After FP reports to several vendors, it slowly dropped down to 1-2 detections until March 2019. Experience since then suggests that some noise of ~2 detections from not well-known AV is normal. -- 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 slow access to file information
Eliot Moss via Cygwin wrote: I have a separate drive mounted this way: d:/ /cygdrive/d ntfs binary,posix=0,user,noacl,auto 0 0 One thing I use it for is to store backup files. These tend to be 2 Gb chunks, and there can be hundreds of them in the backup directory. (The drive is 5Tb.) The Windows Disk Management tool describes it as NTFS, Basic Data Partition. Doing ls (for example) takes a very perceptible numbers of seconds (though whatever takes a long time seems to be cached, at least for a while, since a second ls soon after is fast). The problem is the 'noacl' mount option and the fact that POSIX only offers the *stat*() functions to retrieve file information. These functions always need to provide the full file information, even if only a small subset is needed. To determine the 'x'-permission bits in the 'stat.st_mode' field on a 'noacl'-mount, Cygwin reads the first bytes of most files (all except *.exe, *.lnk, *.com). The 'x' bits are set if the file starts with "#!" (script), ":\n" (?) or "MZ" (Windows executable). On 'noacl' mounts, this behavior could be suppressed by 'exec' or 'noexec' mount options. -- Regards, Christian -- 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 slow access to file information
Eliot Moss via Cygwin wrote: On 1/15/2023 3:38 AM, Christian Franke via Cygwin wrote: Eliot Moss via Cygwin wrote: I have a separate drive mounted this way: d:/ /cygdrive/d ntfs binary,posix=0,user,noacl,auto 0 0 One thing I use it for is to store backup files. These tend to be 2 Gb chunks, and there can be hundreds of them in the backup directory. (The drive is 5Tb.) The Windows Disk Management tool describes it as NTFS, Basic Data Partition. Doing ls (for example) takes a very perceptible numbers of seconds (though whatever takes a long time seems to be cached, at least for a while, since a second ls soon after is fast). The problem is the 'noacl' mount option and the fact that POSIX only offers the *stat*() functions to retrieve file information. These functions always need to provide the full file information, even if only a small subset is needed. To determine the 'x'-permission bits in the 'stat.st_mode' field on a 'noacl'-mount, Cygwin reads the first bytes of most files (all except *.exe, *.lnk, *.com). The 'x' bits are set if the file starts with "#!" (script), ":\n" (?) or "MZ" (Windows executable). On 'noacl' mounts, this behavior could be suppressed by 'exec' or 'noexec' mount options. Interesting. I removed the noacl from /etc/fstab and restarted all Cygwin processes. The mount program now shows that drive without noacl. It still takes surprisingly long to ls if I have not done so recently. The directory contains ~1200 files. This depends on storage device, sometimes (HDD) on filesystem fragmentation and always on 'ls' options. Plain '/bin/ls' without any arguments does not call stat(). 'ls -s' or 'ls --color=yes' call stat() for each file. 'ls -l' additionally calls getfacl() for each file if on an 'acl' mount. The latter is apparently slower than expected, see below. Here a quick test on a directory with 1 ~3KB files on a NTFS USB drive connected via USB-2 (~28MB/s raw read speed). The first test of each mount variant was done immediately after connecting the drive: $ TIMEFORMAT='%R' 1. mount [-o acl] $ time ls -l > /dev/null 4.282 $ time ls -l > /dev/null 1.322 $ time ls -s > /dev/null 0.404 $ time ls > /dev/null 0.032 2. mount -o noacl $ time ls -l > /dev/null 13.452 $ time ls -l > /dev/null 0.789 $ time ls -s > /dev/null 0.764 $ time ls > /dev/null 0.033 3. mount -o noacl,noexec $ time ls -l > /dev/null 3.215 $ time ls -l > /dev/null 0.368 $ time ls -s > /dev/null 0.355 $ time ls > /dev/null 0.032 -- Regards, Christian -- 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] ddrescue 1.27-1
The following packages have been uploaded to the Cygwin distribution: * ddrescue-1.27-1 GNU ddrescue is a data recovery tool. It copies data from one file or block device (hard disc, cdrom, etc) to another, trying hard to rescue data in case of read errors. Ddrescue does not truncate the output file if not asked to. So, every time you run it on the same output file, it tries to fill in the gaps. https://www.gnu.org/software/ddrescue/ddrescue.html This is an update to the latest upstream release. - Changes in version 1.27: A deadlock in command mode when stdout is fully buffered has been fixed by flushing stdout after executing each command. The new option '-W, --compare-before-write' has been added. It omits superfluous writes in rescue mode. Diagnostics caused by invalid arguments to command line options now show the argument and the name of the option. The option synonym '--direct' has been removed and is no longer recognized. 'long long' is now used instead of 'long' for time variables. - Changes in version 1.26: While writing the mapfile, ddrescue now checks the return value of each call to 'fprintf' to catch any temporary failure of 'fprintf' not reported by the system when closing the file. Domain mapfiles may now contain unordered and overlapping blocks when '-L, --loose-domain' is specified as long as no block overlaps with other block of different status. Ddrescue now shows the file name in all the diagnostics with a file involved. Ddrescue now exits with status 1 on fatal read errors. Empty phases are now completely skipped. Ddrescue now scrolls forward after each pass. This keeps on the screen the final status of the previous pass, making it easier to estimate the amount of work done by the current pass. In case of error in a numerical argument to a command line option, ddrescue now shows the name of the option and the range of valid values. The option synonyms '--*-logfile' and '--pause' have been removed and are no longer recognized. Ddrescuelog now can convert between mapfiles and bitmaps of blocks (big and little endian). The new option '-F, --format' has been added to ddrescuelog. It selects the input format for '--create-mapfile', or the output format for '--list-blocks'. Option '-d, --delete-if-done' of ddrescuelog no longer returns an error if the mapfile is read from standard input. Instead it behaves like '-D, --done-status' because there is nothing to delete. 'ddrescuelog --show-status' now rounds percentages up to get the sum closer to 100%. The description of the algorithm in the manual has been improved. Regards, Christian Franke -- 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: groff-1.23.0-1
ASSI via Cygwin wrote:
GNU roff has been updated to the latest upstream version 1.23.0. The
following packages are available on Cygwin:
groff-1.23.0-1
groff-perl-1.23.0-1
groff-X11-1.23.0-1
- Various PDF fonts produce warnings but seem to work in general:
$ echo "Hello, World!" | groff -Tpdf -f A > hello.A.pdf
/usr/bin/gropdf: warning: The download file in
'/usr/share/groff/1.23.0/font/devpdf' has erroneous entry for
'AvantGarde-Book (AR)'
$ grep -a BaseFont hello.A.pdf
5 0 obj << /BaseFont /AvantGarde-Book
Affected are all except T(imes), H(elvetica) and C(ourier).
This script tests all PDF fonts for warnings:
===
#!/bin/sh
(cd /usr/share/groff/current/font/devpdf && ls -d *R 2>/dev/null) \
| while read f; do
f=${f%R}
echo "$f:"
echo "Hello, World!" | groff -Tpdf -f "$f" > "hello.$f.pdf"
done
===
- Man pages could no longer be formatted with a specific font. Only
header and footer lines use the selected font then, the rest stays at
the default font 'T':
$ zcat /usr/share/man/man1/ls.1.gz | groff -man -Tpdf -f H > ls.1.H.pdf
$ grep -a BaseFont ls.1.H.pdf
6 0 obj << /BaseFont /Helvetica-Oblique
10 0 obj << /BaseFont /Helvetica
13 0 obj << /BaseFont /Times-Bold
16 0 obj << /BaseFont /Times-Roman
19 0 obj << /BaseFont /Times-Italic
Intentional change or regression?
--
Regards,
Christian
--
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: groff-1.23.0-1
ASSI via Cygwin wrote: Christian Franke via Cygwin writes: ASSI via Cygwin wrote: - Various PDF fonts produce warnings but seem to work in general: $ echo "Hello, World!" | groff -Tpdf -f A > hello.A.pdf /usr/bin/gropdf: warning: The download file in '/usr/share/groff/1.23.0/font/devpdf' has erroneous entry for 'AvantGarde-Book (AR)' WJFFM. You need to have groff-perl and urw-base35-fonts-legacy installed. groff-perl is installed, otherwise groff would complain about a missing DESC file. Installing urw-base35-fonts-legacy fixes this, thanks. It is IMO not obvious for the occasional groff user that this package is needed. - Man pages could no longer be formatted with a specific font. Only header and footer lines use the selected font then, the rest stays at the default font 'T': […] Intentional change or regression? IDK, ask upstream. OK, will do. Didn't find anything similar here: https://savannah.gnu.org/bugs/?group=groff IMO a regression, obvious in the postscript output: $ groff -man -T ps -f H <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: groff-1.23.0-1
Christian Franke via Cygwin wrote: ... - Man pages could no longer be formatted with a specific font. Only header and footer lines use the selected font then, the rest stays at the default font 'T': […] Intentional change or regression? IDK, ask upstream. OK, will do. Didn't find anything similar here: https://savannah.gnu.org/bugs/?group=groff IMO a regression, obvious in the postscript output: $ groff -man -T ps -f H < Found the issue: T(imes) is unconditionally stored to a variable which is used by SH macro: $ cat /usr/share/groff/1.23.0/tmac/an.tmac ... .de1 SH . fam \\*[an*body-family] ... .ds an*body-family T \" Times ... Fixed upstream in: http://git.savannah.gnu.org/cgit/groff.git/commit/tmac/an.tmac?id=6e03ad16ea8ed053fbffb5296d2670d6cdb4e931 Postscript output looks sane then: %%EndPageSetup /F0 10/Helvetica-Oblique@0 SF -.4(TO)72 48 S(OL).4 E/F1 10/Helvetica@0 SF 174.995(\(1\) Section).5 F F0 -.4(TO)177.775 G(OL).4 E F1(\(1\)).5 E /F2 10.95/Helvetica-Bold@0 SF(NAME)72 84 Q F1 -1.2(To)108 96 S (ol \255 do something interesting)1.2 E -1.2(To)72 768 S 174.06 (olset 2023-07-23)1.2 F(1)202.87 E 0 Cg EP %%Trailer -- Regards, Christian -- 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: Cygwin console: Different default background color when terminal runs as Admin?
Jonathon Merz via Cygwin wrote:
On Thu, Aug 17, 2023 at 7:13 PM Martin Wege via Cygwin
wrote:
Just an idea: Could the default background color of the Cygwin console
be changed from black to grey (or RED) if the terminal has been
started with Administrator rights?
Assuming that:
1. The Administrators group is called "Administrators"
2. There aren't any non-administrative groups with "Administrators" in the
name
3. You're using mintty for your terminal
You can run the following in bash or zsh with the desired RGB values:
if [[ `id -Gn` == *Administrators* ]]
then
echo -ne "\e]11;#FFBBEE\a";
fi
A alternative that should work with any shell, does not rely on
(unfortunately localized) group names and only assumes that the
Administrators group S-1-5-32-544 isn't remapped by /etc/group:
case " $(/usr/bin/id -G) " in
*\ 544\ *) printf '\e]11;#80\a' ;;
esac
Or use a check of actual access rights:
if [ -r /proc/registry/HKEY_LOCAL_MACHINE/SAM/SAM ]; then ...; fi
I use this in .bashrc to add "(root)" to the default mintty title and
set '#' as root prompt:
case " $(/usr/bin/id -G) " in
*\ 544\ *) PS1=${PS1/\\e]0;\\w/\\e]0;\\w (root)}; PS1=${PS1/\\\$ /\# } ;;
esac
--
Regards
Christian
--
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: Cygwin console: Different default background color when terminal runs as Admin?
Corinna Vinschen via Cygwin wrote: On Aug 18 11:51, Martin Wege via Cygwin wrote: On Fri, Aug 18, 2023 at 7:27 AM Jonathon Merz via Cygwin wrote: On Thu, Aug 17, 2023 at 7:13 PM Martin Wege via Cygwin wrote: Just an idea: Could the default background color of the Cygwin console be changed from black to grey (or RED) if the terminal has been started with Administrator rights? Assuming that: 1. The Administrators group is called "Administrators" 2. There aren't any non-administrative groups with "Administrators" in the name 3. You're using mintty for your terminal You can run the following in bash or zsh with the desired RGB values: if [[ `id -Gn` == *Administrators* ]] then echo -ne "\e]11;#FFBBEE\a"; fi Looking at the output of /usr/bin/id -a was my first guess too. But this fails quickly because the names are localized. Seriously MS runs the Windows group names through the l10n wringer!! So what works on Windows for Germany will surely fail for Windows for Japan. Thus I am looking for a more portable solution. Maybe the numeric group ids are more 'portable' across the Windows versions for different countries? Admin group is always Windows SID 1-5-32-544 and gid 544 in Cygwin, unless somebody overloads the gid values via an /etc/group file. If you want to be really sure, you have to check every numeric gid returned by `id -G' if it resolves to SID 1-5-32-544. You can do this with the getent(1) tool. Fortunately getent allows multiple keys, so this works: case "$(getent group $(id -G))" in *:S-1-5-32-544:*) echo admin ;; esac Unfortunately this may be is slow in domains due to unneeded AD requests. Unlike mkgroup, getent output cannot be restricted to local groups (and the '-s SERVICE' option is apparently a no-op). -- Regards, Christian -- 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] busybox 1.36.1-1
The following packages have been uploaded to the Cygwin distribution:
* busybox-1.36.1-1
* busybox-standalone-1.36.1-1
* busybox-doc-1.36.1-1
BusyBox combines tiny versions of many (un)common utilities into a
single executable. It is still smaller than bash.
https://busybox.net/about.html
This is an update to the latest upstream release.
Changes since the last Cygwin package 1.23.2-1:
Functions added upstream which are enabled for Cygwin:
arch, ascii, base32, bc, crc32, factor, fallocate, hexedit, link,
mim, nl, nproc, paste, setfattr, shred, ssl_client, svc, svok, tree,
tr, truncate, ts, tsort, xxd
Enhanced functions:
wget (added HTTPS support, certificates are not checked)
Previously disabled functions which are now enabled:
fdisk (provides R/W MBR and R/O GPT support)
Previously enabled functions which are now disabled:
catv (now supported by 'cat -v')
smemcap (requires /proc/PID/smaps)
The source package is prepared for reproducible builds.
Packages:
- busybox: busybox and symlinks for all supported functions installed in
/usr/libexec/busybox/{bin,sbin}.
- busybox-standalone: busybox compiled with 'standalone shell' feature
installed in /usr/libexec/busybox-standalone/bin.
- busybox-doc: man page and documentation files.
The busybox and busybox-standalone packages install a symlink to
busybox.exe in /usr/bin with alternatives(8). If both packages are
installed, the non-standalone version takes precedence.
The included 'ash' shell provides reasonable support for interactive
usage (command line editing, history search, job control, aliases, fancy
prompts, ...).
A tiny version of Cygwin could be created by copying
/usr/libexec/busybox{,-standalone} tree and adding cygwin1.dll to .../bin.
See the /usr/share/doc/Cygwin/busybox.README file for usage examples and
further info.
Supported functions:
$ busybox
BusyBox v1.36.1 (2023-09-15 12:00:00 UTC) multi-call binary.
BusyBox is copyrighted by many authors between 1998-2015.
Licensed under GPLv2. See source distribution for detailed
copyright notices.
Usage: busybox [function [arguments]...]
or: busybox --list[-full]
or: busybox --show SCRIPT
or: busybox --install [-s] [DIR]
or: function [arguments]...
BusyBox is a multi-call binary that combines many common Unix
utilities into a single executable. Most people will create a
link to busybox for each function they wish to use and BusyBox
will act like whatever it was invoked as.
Currently defined functions:
[, [[, add-shell, ar, arch, ascii, ash, awk, base32, base64,
basename, bash, bbconfig, bc, bunzip2, bzcat, bzip2, cal, cat,
chat, chgrp, chmod, chown, chpst, chroot, cksum, clear, cmp,
comm, cp, cpio, crc32, crond, crontab, cryptpw, cttyhack, cut,
date, dc, dd, df, diff, dirname, dnsd, dnsdomainname, dos2unix,
du, echo, ed, egrep, env, envdir, envuidgid, expand, expr,
factor, fakeidentd, fallocate, false, fdisk, fgrep, find,
flock, fold, free, fsync, ftpd, ftpget, ftpput, fuser, getopt,
grep, groups, gunzip, gzip, hd, head, hexdump, hexedit, hostid,
hostname, httpd, hush, id, inetd, install, ipcalc, ipcrm, kill,
killall, killall5, less, link, ln, logger, login, logname,
logread, lpd, lpq, lpr, ls, lsof, lzcat, lzma, lzop, lzopcat,
makedevs, makemime, man, md5sum, mesg, microcom, mim, mkdir,
mkfifo, mknod, mktemp, more, mountpoint, mpstat, mt, mv, nc,
netcat, nice, nl, nmeter, nohup, nproc, nslookup, od, paste,
patch, pgrep, pidof, ping, ping6, pipe_progress, pkill,
popmaildir, printenv, printf, ps, pscan, pstree, pwd, pwdx,
readlink, realpath, reformime, remove-shell, renice, reset,
resize, rm, rmdir, rpm, rpm2cpio, run-parts, runsv, runsvdir,
rx, script, scriptreplay, sed, sendmail, seq, setfattr, setsid,
setuidgid, sh, sha1sum, sha256sum, sha3sum, sha512sum, shred,
shuf, sleep, softlimit, sort, split, ssl_client,
start-stop-daemon, stat, strings, stty, sum, sv, svc, svlogd,
svok, sync, syslogd, tac, tail, tar, tcpsvd, tee, telnet,
telnetd, test, tftp, tftpd, time, timeout, top, touch, tr,
traceroute, tree, true, truncate, ts, tsort, tty, ttysize,
udpsvd, uname, uncompress, unexpand, uniq, unix2dos, unlink,
unlzma, unlzop, unxz, unzip, uptime, usleep, uudecode,
uuencode, vi, volname, watch, wc, wget, which, whoami, whois,
xargs, xxd, xz, xzcat, yes, zcat
$ busybox ash -c help
Built-in commands:
--
. : [ [[ alias bg break cd chdir command continue echo eval exec
exit export false fg getopts hash help history jobs kill let
local printf pwd read readonly return set shift sleep source
test times trap true type ulimit umask unalias unset wait
Regards,
Christian
--
Problem reports: https://cygwin.com/problems.html
FAQ: h
cygport may not create debug info if top directory contains a symlink
Found during tests of busybox package:
If the path of the top build directory contains a symlink and the
project's build scripts normalize pathnames, no debug info is created by
cygport.
This is because options like
-fdebug-prefix-map=${B}=/usr/src/debug/${PF}
have no effect because ${B} contains a symlink but the compiler is run
with the real source path.
The postinstall code then does not find any line number info with source
path /usr/src/debug/${PF}/...
Could be fixed easily in line 414 of /bin/cygport:
-declare -r top=$(cd ${_topdir}; pwd);
+declare -r top=$(cd ${_topdir}; /bin/pwd);
No patch provided because I'm not sure whether this has other negative
side effects.
If this is the case, it possibly makes sense to print a warning if
"$(pwd)" != "$(/bin/pwd)".
--
Regards,
Christian
--
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: std::runtime_error on std::locale("")
Brian Inglis via Cygwin wrote:
On 2023-09-21 10:28, Takashi Yano via Cygwin wrote:
On Fri, 22 Sep 2023 01:12:04 +0900
Takashi Yano wrote:
I wonder why the following code throws std::runtime_error
even though the LC_ALL is set to valid locale other than "C".
This does not occur only when LC_ALL is set to "C".
#include
int main()
{
std::locale("");
return 0;
}
In linux, this occurs only when the LC_ALL is set to invalid
locale (i.e. locale that is not registered in system).
Similarly,
std::locale("ja_JP.UTF-8")
throws std::runtime_error in cygwin.
Looks like the implementation does not like any default "" or explicit
"en_US.UTF-8" strings there! See example at link and below; results
are always the same:
https://en.cppreference.com/w/cpp/locale/locale
#include
#include
int main()
{
std::wcout << "User-preferred locale setting is "
<< std::locale().name().c_str() << '\n';
// on startup, the global locale is the "C" locale
std::wcout << 1000.01 << '\n';
// replace the C++ global locale and the "C" locale with the
user-preferred locale
std::locale::global(std::locale(""));
// use the new global locale for future wide character output
std::wcout.imbue(std::locale());
// output the same number again
std::wcout << 1000.01 << '\n';
}
$ g++ -o c++locale{,.cc}
$ ./c++locale
User-preferred locale setting is C
1000.01
terminate called after throwing an instance of 'std::runtime_error'
what(): locale::facet::_S_create_c_locale name not valid
Aborted (core dumped)
According to libstdc++ source, the internal function
locale::facet::_S_create_c_locale() calls some __newlocale() which
apparently does not arrive at newlocale() from cygwin1.dll. But
cygstdc++-6.dll imports newlocale() from cygwin1.dll.
Only standard locale "C" and its alias "POSIX" work with C++ std::locale().
The cygwin1.dll function newlocale() works as expected - except that it
does not set errno if the locale name is invalid.
--
Regards,
Christian
--
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: std::runtime_error on std::locale("")
Takashi Yano via Cygwin wrote:
On Thu, 21 Sep 2023 21:06:59 +0200
Christian Franke wrote:
...
According to libstdc++ source, the internal function
locale::facet::_S_create_c_locale() calls some __newlocale() which
apparently does not arrive at newlocale() from cygwin1.dll. But
cygstdc++-6.dll imports newlocale() from cygwin1.dll.
Thanks for the pointer. I looked into the cygstdc++6.dll source code,
and noticed that the code you mentioned is for glibc. In glibc,
__newlocale() is defined and newlocale() is a weak alias for that.
For generic libc (i.e. other than glibc), _S_create_c_locale() is
defined as:
void
locale::facet::_S_create_c_locale(__c_locale& __cloc, const char* __s,
__c_locale)
{
// Currently, the generic model only supports the "C" locale.
// See http://gcc.gnu.org/ml/libstdc++/2003-02/msg00345.html
__cloc = 0;
if (strcmp(__s, "C"))
__throw_runtime_error(__N("locale::facet::_S_create_c_locale "
"name not valid"));
}
in /libstdc++-v3/config/locale/generic/c_locale.cc.
Thanks for clarification. Same applies to MinGW-w64 runtime.
The reason why cygstdc++-6.dll imports newlocale() and other *locale()
from cygwin1.dll are only the C++17 std::from_chars() functions
(src/c++17/floating_from_chars.cc). These switch temporarily to "C"
locale. MinGW-w64 does not support these.
--
Regards,
Christian
--
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: Running bash script as SYSTEM from account with admin rights?
Martin Wege via Cygwin wrote: Hello, Does Cygwin have a tool to run a bash script as SYSTEM user if my account already have admin rights? No (AFAIK). I use psexec from Sysinternals tools (https://learn.microsoft.com/sysinternals/downloads/psexec) This starts a Cygwin terminal as SYSTEM user: psexec -s -i c:\cygwin\bin\mintty - -- Regards, Christian -- 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: Running bash script as SYSTEM from account with admin rights?
Martin Wege via Cygwin wrote: On Fri, Sep 22, 2023 at 9:42 AM Christian Franke via Cygwin wrote: Martin Wege via Cygwin wrote: Hello, Does Cygwin have a tool to run a bash script as SYSTEM user if my account already have admin rights? No (AFAIK). I use psexec from Sysinternals tools (https://learn.microsoft.com/sysinternals/downloads/psexec) This starts a Cygwin terminal as SYSTEM user: psexec -s -i c:\cygwin\bin\mintty - Use of psexec is forbidden, as it triggers our security software (Cortex XDR). Then it is possibly not recommended to do anything special that psexec could do, except if there exists an explicit permission :-) Windows has https://learn.microsoft.com/en-us/windows/win32/api/securitybaseapi/nf-securitybaseapi-impersonateloggedonuser Can we use that to write a C wrapper program, to switch from current user with admin rights to the SYSTEM account, execute command and then exit(0) the wrapper? Function from this API are also used by the setuid() emulation of Cygwin (https://cygwin.com/cygwin-ug-net/ntsec.html#ntsec-setuid-overview). User switching relies on an access token returned by LogonUser() or similar. This requires a password or other credential which is (AFAIK) never available for the SYSTEM user. Windows services are run as SYSTEM by default. Running the script with bash installed as a service (via cygrunsrv) may do the trick. -- Regards, Christian -- 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: /usr/bin/dd *.iso to USB stick?
Jim Garrison via Cygwin wrote: On 9/21/2023 22:40, Martin Wege via Cygwin wrote: Hello, How can I use /usr/bin/dd to copy a *.iso image (Debian netinstall boot image) to a USB stick as raw bytes? I do this frequently. You must start the Cygwin shell with admin rights, then use Windows Disk Management mmc app to identify the disk and convert from Disk n to /dev/sd[x], where Disk 0 is /dev/sda, Disk 1 is /dev/sdb, etc. BIG CAVEAT: You're in admin mode. Use the wrong device name and you will trash target device if it's writable, including your Windows boot drive. And no, the boot drive is not always Disk0 /dev/sda. I always use hexedit to examine enough of the target device to assure myself that it's the correct target. This is much easier if 'ddrescue --ask' is used instead of 'dd' (https://cygwin.com/packages/summary/ddrescue.html). It prints device size, identify string and serial "number" string if available and asks for confirmation then: # ddrescue --ask --force image.iso /dev/sde GNU ddrescue 1.27 About to copy 4671 MBytes from 'image.iso' (4_562_040Ki) to '/dev/sde' [Kingston DataTraveler 3.0::EE03D85142E0] (14_784Mi) Proceed (y/N)? y ... Device identity is also printed if the destination is a partition (/dev/sde1) on that device. The --force (-f) option is required if the destination is not a regular file. Note that for (S)ATA devices, the serial may be printed in the unusual LE word string byte order from ATA IDENTIFY data. This is a minor bug in some layer behind IOCTL_STORAGE_QUERY_PROPERTY. ddrescue also works with some /proc/sys block devices as source, for example /proc/sys/Device/HarddiskVolumeShadowCopy2 or /proc/sys/Device/VeraCryptVolumeF It could also be run from the limited WinPE environment, for example to create an image of C: if not booted. -- Regards, Christian -- 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 2.927 release candidate - please test
Jon Turney via Cygwin wrote: A new setup release candidate is available at: ... - Translation updates. - Add German and Polish translations (thanks to weblate contributors Markus, Ettore Atalan, Luis Mengel and WaldiS) Some small adjustments have been made to the layout of the dialog templates to accommodate places where the translation is longer. Please report it if there are any spots I've missed where the text overflows the space available. The IDC_CHOOSE_SYNC button with German text "Synchronisieren" overlaps with "Test" checkbox: "(.) Synchronisier[.] Test" Could be fixed by increasing res.rc:SETUP_KPCE_W from 52 to 60 (the three radio buttons IMO do not look "nice" then), or by an individual adjustment like: - CONTROL "&Beste",IDC_CHOOSE_BEST,...,SETUP_BEST_X,30,SETUP_KPCE_W,14 - CONTROL "&Synchronisieren",IDC_CHOOSE_SYNC,...,SETUP_SYNC_X,30,SETUP_KPCE_W,14 + CONTROL "&Beste",IDC_CHOOSE_BEST,"Button",...,SETUP_BEST_X,30,SETUP_KPCE_W-10,14 + CONTROL "&Synchronisieren",IDC_CHOOSE_SYNC,...,SETUP_SYNC_X-12,30,SETUP_KPCE_W+12,14 or by simply using an abbreviation like "Synchr.". -- Regards, Christian -- 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: Run a Cygwin process with "higher" scheduler priority
Brian Inglis via Cygwin wrote:
On 2023-10-14 07:47, Eliot Moss via Cygwin wrote:
On 10/14/2023 7:39 AM, Cedric Blancher via Cygwin wrote:
On Fri, 11 Aug 2023 at 19:14, Brian Inglis wrote:
...
...
$ cygcheck -p usr/bin/chrt
Found 2 matches for usr/bin/chrt
util-linux-debuginfo-2.33.1-2 - util-linux-debuginfo: Debug info
for util-linux
util-linux-2.33.1-2 - util-linux: Collection of basic system utilities
$ cygcheck -p usr/bin/taskset
Found 2 matches for usr/bin/taskset
util-linux-debuginfo-2.33.1-2 - util-linux-debuginfo: Debug info
for util-linux
util-linux-2.33.1-2 - util-linux: Collection of basic system utilities
so you may need to install util-linux (coreutils is already
installed as a base
package for Cygwin) then:
$ man nice renice taskset chrt
chrt does not work, the syscalls for realtime seem to be not
implemented.
These are partly implemented, but sched_setscheduler() always fails with
ENOSYS because scheduler policy (SCHED_*) cannot be changed on Windows.
Changing priority only with sched_setparam() would work, but this is not
used by chrt.
You may need to run these from an elevated admin shell for other
user ids,
unowned processes, or higher (negative) priority.
It has been years since I tried these so can no longer remember if -20
corresponds to Windows "RealTime" or if you need to use PowerShell
to set that e.g.
$proc = Get-Process -ProcessName "..."
$proc.PriorityClass = "RealTime"
and that needs to be done from an elevated admin (Power)Shell.
Of course, never set that on any system except on a very idle, very
I/O bound,
well tested process, such as ntpd, that needs stably fast interrupt
service and
non-preemptible cpu access for ms every few seconds, preferably on
a single or
few cpus to which affinity is set.
Is there anything in /proc which can tell me the current *Windows*
scheduler priority level? Or a command line tool?
I recall getting taskset going in util-linux a while back, but I don't
recall working on priority related things. You could look into the
cygwin source code to see how Windows priorities relate to the priority
values in Cygwin. Then you may be able just to use /proc/[pid]/stat
read out what you want.
ISTR testing nice/renice, and found it was a simple priority mapping
to/from Unix to Windows Idle to RealTime (at the time, process
Affinity was not supported, so went with a PowerShell startup script
instead); see:
https://cygwin.com/git/?p=newlib-cygwin.git;a=blob;f=winsup/cygwin/sched.cc#l107
https://cygwin.com/git/?p=newlib-cygwin.git;a=blob;f=winsup/cygwin/sched.cc#l234
https://cygwin.com/git/?p=newlib-cygwin.git;a=blob;f=winsup/cygwin/sched.cc#l277
The above maps priorities for sched_*() API. The mapping for nice() and
get/setpriority() is done here:
https://cygwin.com/git/?p=newlib-cygwin.git;a=blob;f=winsup/cygwin/miscfuncs.cc;h=767384f#l110
They are documented in proc(5) /proc/PID/stat fields 18 priority and
19 nice typically 20 and 0, as shown by `top` PR and NI, shown by
`procps -l` as 80 and 0, and not shown by Cygwin `ps`.
On Cygwin, field 18 is always equal to (field_19 + 20). The priority
value returned by sched_getparam() is different and could be shown with
'chrt -p PID'.
The output from the command 'nice' without parameter may differ from
/proc/PID/stat field 19 because the latter always reinterprets the
current Windows prio class.
This script prints a table of 'nice' outputs, /proc/PID/stat fields 19
and 18, result of sched_getparam() and corresponding Windows prio class
for different 'nice -n ...' commands:
#!/bin/bash
echo "COMMAND : NICE STAT STPRI RTPRI WINPRI"
for i in {-21..20}; do
nice -n $i sh -e -c '
n=$(nice)
s=$(cut -d" " -f19 /proc/$$/stat)
p=$(cut -d" " -f18 /proc/$$/stat)
r=$(LC_MESSAGES=C chrt -p $$ | sed -n "s,^.*priority: ,,p")
case $r in
3) c="IDLE_PRIORITY_CLASS" ;;
9) c="BELOW_NORMAL_PRIORITY_CLASS" ;;
15) c="NORMAL_PRIORITY_CLASS" ;;
21) c="ABOVE_NORMAL_PRIORITY_CLASS" ;;
27) c="HIGH_PRIORITY_CLASS" ;;
32) c="REALTIME_PRIORITY_CLASS" ;;
*) c="?" ;;
esac
printf "nice -n %3d:%5d %5d %5d %5d %s\\n" \
"'$i'" "$n" "$s" "$p" "$r" "$c"
'
done
--
Regards,
Christian
--
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: where is parted?
Matthias--- via Cygwin wrote: I'm using sfdisk for analysing partitions on msdos partition tables. Unfortunately it don't support GPT tables. Is there another tool, like parted, what can be used? /sbin/fdisk from package util-linux-2.33.1-2 supports GPT. -- Regards, Christian -- 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: where is parted?
matth...@gmx.li wrote: fdisk reports the same partition type as sfdisk. It report "Microsoft basic data" for NTFS as well as for FAT32 partitions. That is as expected and differs from MBR disks. The same GPT partition GUID is used for NTFS and the various FAT filesystem types. https://en.wikipedia.org/wiki/Microsoft_basic_data_partition -- 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: Add ability to hide non-standard itoa/utoa() in stdlib.h ?
Corinna Vinschen via Cygwin wrote: On Jan 22 16:47, Christian Franke via Cygwin wrote: Busybox does not build OOTB on Cygwin due to the addition of itoa/utoa() to newlib in 2014: https://cygwin.com/git/?p=newlib-cygwin.git;a=commit;h=32c96dd This is because Busybox use local functions with same name but different signature. This does not affect build on FreeBSD, Linux (glibc, musl libc), ... because these functions simply do not exits there. For the busybox Cygwin package, I use an ugly local hack to fix this. itoa() is mentioned as a non-standard extension here: https://en.wikibooks.org/wiki/C_Programming/stdlib.h/itoa https://cplusplus.com/reference/cstdlib/itoa/ MSVC provides itoa() as a "POSIX version" of _itoa(): https://learn.microsoft.com/cpp/c-runtime-library/reference/itoa-itow But SUS-1997... POSIX-2018 do not mention these functions: https://pubs.opengroup.org/onlinepubs/7908799/ https://pubs.opengroup.org/onlinepubs/9699919799/ Newlib guards the prototypes with __MISC_VISIBLE in stdlib.h and sys/features.h says: * __MISC_VISIBLE * Extensions found in both BSD and SVr4 (shorthand for * (__BSD_VISIBLE || __SVID_VISIBLE)), or newlib-specific * extensions; enabled by default. __MISC_VISIBLE is set if and only if _DEFAULT_SOURCE is set, so the comment below should also include "... or newlib-specific extensions": * _DEFAULT_SOURCE (or none of the above) * POSIX-1.2008 with BSD and SVr4 extensions The above is not suitable to disable only the non-standard functions for such use cases. Using -D_GNU_SOURCE should IMO not enable functions unavailable on Linux. This is not the case because _GNU_SOURCE implies _DEFAULT_SOURCE. No patch provided for now, as I'm not yet sure how to handle this. Possibly: - Use __MISC_VISIBLE only for (__BSD_VISIBLE || __SVID_VISIBLE) - under the assumption that this is applicable for most cases. - Introduce __NONSTD_VISIBLE for non-standard functions like itoa(). - Introduce _NONSTD_SOURCE to set __NONSTD_VISIBLE independent from other _*_SOURCE defines. Counter proposal: First of all, Cygwin does NOT export itoa/utoa! Only the prototypes exist from the Cygwin POV. Thanks, I missed that. As Cygwin is usually the only newlib project with backward compat issues, we have two simple choices: - Drop itoa/utoa entirely, or - just guard them with #if __MISC_VISIBLE && !defined (__CYGWIN__) You can make a proposal like that on the newlib list and then we can discuss it there, ok? Done. -- 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
Cygwin build from source is broken since binutils-2.42-1
This is not a binutils regression: A build from cygwin 3.5.0-1 src package or current newlib-cygwin git main (bfb68a9) with new binutils-2.42-1 fails with: " In file included from ../../../../winsup/utils/dumper.cc:23: /usr/include/bfd.h:2748:1: error: expected initializer before ‘ATTRIBUTE_WARN_UNUSED_RESULT’ " Downgrading to binutils 2.41-3 fixes the problem. A diff of /usr/include/bsd.h shows that ATTRIBUTE_WARN_UNUSED_RESULT is a new addition in 2.42-1. This requires /usr/include/ansidecl.h. It is included by /usr/include/bsd.h but this has no effect because Cygwin source tree provides its own ansidecl.h which lacks ATTRIBUTE_WARN_UNUSED_RESULT: $ g++ MANY_OPTIONS... -E ../../../../winsup/utils/dumper.cc ... # 1 "../../../../winsup/utils/dumper.cc" ... # 1 "../../../../winsup/../include/ansidecl.h" 1 <== #define _ANSIDECL_H ... # 1 "/usr/include/bfd.h" 1 3 4 ... # 1 "/usr/include/ansidecl.h" 1 3 4 <== #ifndef _ANSIDECL_H ... -- Regards, Christian -- 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: cygport 0.36.8-1
Jon Turney wrote on cygwin-announce list: The following packages have been uploaded to the Cygwin distribution: * cygport-0.36.8-1 cygport is the standard method for building and maintaining packages for the Cygwin distribution. ... Add initial support for SOURCE_DATE_EPOCH Testcase with Cygwin 3.5.0-1 src package: - using current non-test packages including g++ 11.4.0, but - binutils needs to be downgraded to 2.41-3 (see my related recent post on this list) Then this command apparently produces reproducible packages: cd /usr/src/cygwin-3.5.0-1.src && SOURCE_DATE_EPOCH=1704974400 cygport ./cygwin.cygport all This requires that always the same build directory is used. I attached the package checksums in case someone is willing to repeat the test. It also worked with the following of my packages, regardless of build directory: busybox-1.36.1-1, ddrescue-1.28-1, smartmontools-7.4-1 (busybox and smartmontools have SOURCE_DATE_EPOCH already set in the cygport file) -- Regards, Christian b4362a4df2688819e34555173c5f843f *cygwin-3.5.0-1.x86_64/dist/cygwin/cygwin-3.5.0-1-src.hint 17c671cf6fd3f96cca4b7c411bf5c893 *cygwin-3.5.0-1.x86_64/dist/cygwin/cygwin-3.5.0-1-src.tar.xz 4d11453011e43fd0e97fdba04fbf *cygwin-3.5.0-1.x86_64/dist/cygwin/cygwin-3.5.0-1.hint 1b97eefb0a3ee5606076dd12abe00ae1 *cygwin-3.5.0-1.x86_64/dist/cygwin/cygwin-3.5.0-1.tar.xz bd8cfd72f3cffeada421debc9ac06f01 *cygwin-3.5.0-1.x86_64/dist/cygwin/cygwin-debuginfo/cygwin-debuginfo-3.5.0-1.hint ca80ee415c134c691a5edc2cb5cc6507 *cygwin-3.5.0-1.x86_64/dist/cygwin/cygwin-debuginfo/cygwin-debuginfo-3.5.0-1.tar.xz 1fcf6f79fc6bb1e05eb7c45fcf9c157e *cygwin-3.5.0-1.x86_64/dist/cygwin/cygwin-devel/cygwin-devel-3.5.0-1.hint a5255ae6047d9d7e4a97503f1b708696 *cygwin-3.5.0-1.x86_64/dist/cygwin/cygwin-devel/cygwin-devel-3.5.0-1.tar.xz b761a8949c7e843d43eb97375be53576 *cygwin-3.5.0-1.x86_64/dist/cygwin/cygwin-doc/cygwin-doc-3.5.0-1.hint 06ce0286241c7404a02c1d094cf7e33c *cygwin-3.5.0-1.x86_64/dist/cygwin/cygwin-doc/cygwin-doc-3.5.0-1.tar.xz -- 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: cygport 0.36.8-1
Jon Turney via Cygwin wrote:
On 12/02/2024 16:49, ASSI via Cygwin wrote:
Christian Franke via Cygwin writes:
This requires that always the same build directory is used.
Would that be solvable by using -ffile-prefix-map or is there more to
it?
That should now be used in 0.36.8, so something else leaking the local
build directory into the package, perhaps
A closer look shows that (only) the pathnames of the assembly (*.S)
files in cygwin1.dll.dbg now contain the build path instead of the
mapped path:
$ strings cygwin1.dll.dbg | grep '^/.*bcopy\.S$' | uniq
/tmp/build/cygwin-3.5.0-1.x86_64/src/newlib-cygwin/winsup/cygwin/x86_64/bcopy.S
The paths in the released package are correct:
$ strings /usr/lib/debug/usr/bin/cygwin1.dll.dbg | grep '^/.*bcopy\.S$'
| uniq
/usr/src/debug/cygwin-3.5.0-1/winsup/cygwin/x86_64/bcopy.S
The regression was introduced by cygport commit 9e82685 in conjunction
with the fact that --file-prefix-map has no effect on *.S files:
Testcase:
$ cygcheck -f /bin/as
binutils-2.42-1
$ cygcheck -f /bin/gcc
gcc-core-11.4.0-1
$ pwd
/tmp/build
$ echo ret > a.S
$ echo > c.c
$ gcc -c -g --file-prefix-map=/tmp/build=/foo/bar a.S c.c
$ strings -f *.o | grep ': /' | uniq
a.o: /tmp/build
c.o: /foo/bar
$ gcc -c -g --debug-prefix-map=/tmp/build=/foo/bar a.S c.c
$ strings -f *.o | grep ': /' | uniq
a.o: /foo/bar
c.o: /foo/bar
Also gcc builtin specs show that --file-prefix-map is not handled for asm:
$ gcc -dumpspecs | fgrep -A1 '*asm_debug:'
*asm_debug:
%{%:debug-level-gt(0):%{gstabs*:--gstabs;:%{g*:}}}
%{fdebug-prefix-map=*:--debug-prefix-map %*}
--
Regards,
Christian
--
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: cygport 0.36.8-1
Jon Turney via Cygwin wrote:
On 13/02/2024 13:02, Christian Franke via Cygwin wrote:
Jon Turney via Cygwin wrote:
On 12/02/2024 16:49, ASSI via Cygwin wrote:
Christian Franke via Cygwin writes:
This requires that always the same build directory is used.
Would that be solvable by using -ffile-prefix-map or is there more to
it?
That should now be used in 0.36.8, so something else leaking the
local build directory into the package, perhaps
A closer look shows that (only) the pathnames of the assembly (*.S)
files in cygwin1.dll.dbg now contain the build path instead of the
mapped path:
$ strings cygwin1.dll.dbg | grep '^/.*bcopy\.S$' | uniq
/tmp/build/cygwin-3.5.0-1.x86_64/src/newlib-cygwin/winsup/cygwin/x86_64/bcopy.S
The paths in the released package are correct:
$ strings /usr/lib/debug/usr/bin/cygwin1.dll.dbg | grep
'^/.*bcopy\.S$' | uniq
/usr/src/debug/cygwin-3.5.0-1/winsup/cygwin/x86_64/bcopy.S
The regression was introduced by cygport commit 9e82685 in
conjunction with the fact that --file-prefix-map has no effect on *.S
files:
Great. I guess that means we need to use both options.
Also gcc builtin specs show that --file-prefix-map is not handled for
asm:
$ gcc -dumpspecs | fgrep -A1 '*asm_debug:'
*asm_debug:
%{%:debug-level-gt(0):%{gstabs*:--gstabs;:%{g*:}}}
%{fdebug-prefix-map=*:--debug-prefix-map %*}
This kind of seems like a bug.
It is fixed in current gcc test release:
$ cygcheck -f /bin/gcc
gcc-core-13.2.1+20240203-0.1
$ gcc -dumpspecs | fgrep -A1 '*asm_debug:'
*asm_debug:
%{g*:%{%:debug-level-gt(0):}} %{ffile-prefix-map=*:--debug-prefix-map
%*} %{fdebug-prefix-map=*:--debug-prefix-map %*}
--
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: cygport 0.36.8-1
Jon Turney via Cygwin wrote: On 13/02/2024 13:02, Christian Franke via Cygwin wrote: Jon Turney via Cygwin wrote: On 12/02/2024 16:49, ASSI via Cygwin wrote: Christian Franke via Cygwin writes: This requires that always the same build directory is used. Would that be solvable by using -ffile-prefix-map or is there more to it? That should now be used in 0.36.8, so something else leaking the local build directory into the package, perhaps A closer look shows that (only) the pathnames of the assembly (*.S) files in cygwin1.dll.dbg now contain the build path instead of the mapped path: $ strings cygwin1.dll.dbg | grep '^/.*bcopy\.S$' | uniq /tmp/build/cygwin-3.5.0-1.x86_64/src/newlib-cygwin/winsup/cygwin/x86_64/bcopy.S The paths in the released package are correct: $ strings /usr/lib/debug/usr/bin/cygwin1.dll.dbg | grep '^/.*bcopy\.S$' | uniq /usr/src/debug/cygwin-3.5.0-1/winsup/cygwin/x86_64/bcopy.S The regression was introduced by cygport commit 9e82685 in conjunction with the fact that --file-prefix-map has no effect on *.S files: Great. I guess that means we need to use both options. If both --file-prefix-map and --debug-prefix-map are used in cygport, Cygwin 3.5.0-1 build is apparently reproducible.regardless of build path. -- 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.exe suggestions
Hi, Lavrentiev, Anton wrote ... For new installations, it'd be great to have the most suitable (in most cases, the most recent) version shown as the first selection in all those pulldown version lists in the "New" columns. The logical order would be "the preferred (latest) version", "the version previous to that" ... "test version(s)", and then all the actions like "Uninstall"(grayed out), "Skip" (checked) etc coming last, so that one doesn't have to hover different distances when selecting the packages. Doubleclick in "New" column toggles between "Skip" or "Keep" and the "preferred version". Ctrl+I selects the latter.and moves to the next row. ... For existing installations, in the "Unneeded" view it'd be best to have the packages' "New" dispositions as "Uninstall" rather than "Keep", which they presently have showing by default. Changing a view should never change the current package selection. So that one does not have to go through (sometimes quite many) packages in that view to mark them all. Press and hold Ctrl+U to select "Uninstall" for all. Then change to another view and back to "Unneeded" to see more possible unneeded packages. If someone wants to retain some, it's easier to change those few back to "Keep". Ctrl+K = "Keep", Ctrl+R = "Reinstall". -- Regards, Christian -- 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: GetVersionEx() depreciated, what should be used instead for Windows 7/8/10?
Cedric Blancher via Cygwin wrote:
How does cygwin uname -s work, i.e. how does it get the OS version,
revision and build number ('10.0-19045')?
I tried to replicate it via GetVersionEx(), but that is deprecated.
AFAICS, MS does not offer an official way to retrieve the actual Windows
version via the Win32 API layer. GetVersionEx() is unable to detect
Windows versions which are more recent than the compatibility level
advertised in the application manifest.
Cygwin uses the undocumented RtlGetNtVersionNumbers() from ntdll.dll
because even RtlGetVersion() may not return the correct values. See
function wincapc::init()
https://cygwin.com/git/?p=newlib-cygwin.git;a=blob;f=winsup/cygwin/wincap.cc
--
Regards,
Christian
--
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: GetVersionEx() depreciated, what should be used instead for Windows 7/8/10?
Corinna Vinschen via Cygwin wrote: On Mar 19 09:18, Bill Stewart via Cygwin wrote: On Tue, Mar 19, 2024 at 9:01 AM Richard Campbell wrote: On Tue, Mar 19, 2024 at 9:04 AM Bill Stewart via Cygwin wrote: Can you please clarify the circumstances under which the RtlGetVersion function "may not return the correct values"? "Originally, using RtlGetVersion instead of GetVersionEx was supposed to fix the fact that GetVersionInfo returns the wrong kernel version if the executable has been built with an old manifest (or none at all), starting with Windows 8.1. Either this never really worked as desired and our testing was flawed, or this has been changed again with Windows 10, so that RtlGetVersion does the kernel faking twist as well. Since we're only reading the value in the first process in a process tree. the entire process tree is running with a wrong OS version information in that case. Fortunately, the (undocumented) RtlGetNtVersionNumbers function is not affected by this nonsense, so we simply override the OS version info fields with the correct values now." https://cygwin.com/git/?p=newlib-cygwin.git;a=commitdiff;h=48511f3d3847c35352d09cded56e25f0c1b22bc9 Interesting. I have not yet been able to find a scenario where the RtlGetVersion function gets "manifested" like GetVersionEx. I wrote a small Win32 console utility for displaying and testing OS information (requires Windows Vista/Server 2008 or later): https://github.com/Bill-Stewart/osinfo It uses RtlGetVersion, and this function works correctly for me in all current Windows versions (Windows 10, Server 2016, Windows 11, Server 2019, Server 2022, etc.). I'm not sure of the exact scenario that led to the "RtlGetVersion is subject to manifesting" conclusion, but I can't reproduce it. You have to create an application with an application manifest not supporting your OS. For Cygwin apps, this occured when you built, say, an executable under Windows 8.1 before Windows 10 support was added to the Cygwin toolchain: the manifest linked to the Cygwin executable didn't yet contain a GUID entry for Windows 10 support. In this case, RtlGetVersion returns an OS version 6.3 even when running under the 10.0 kernel. This behaviour exists back 'til Windows Vista. Could not reproduce the latter on Win10. I tested with recent Win10 and Win11 and also found a Win10 1511 (and Slackware 1.1.2, Win3.1, OS/2, ...) in my VM image museum. Regardless of the exe manifest, RtlGetVersion and RtlGetNtVersionNumbers return the correct versions: 10.0.22621 (Win11 22H2) 10.0.19045 (Win10 22H2) 10.0.10586 (Win10 1511) Without a manifest, GetVersionEx returns: 6.2.9200 (Win8) -- Regards, Christian -- 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: GetVersionEx() depreciated, what should be used instead for Windows 7/8/10?
Corinna Vinschen via Cygwin wrote: On Mar 20 12:39, Christian Franke via Cygwin wrote: Corinna Vinschen via Cygwin wrote: You have to create an application with an application manifest not supporting your OS. For Cygwin apps, this occured when you built, say, an executable under Windows 8.1 before Windows 10 support was added to the Cygwin toolchain: the manifest linked to the Cygwin executable didn't yet contain a GUID entry for Windows 10 support. In this case, RtlGetVersion returns an OS version 6.3 even when running under the 10.0 kernel. This behaviour exists back 'til Windows Vista. Could not reproduce the latter on Win10. I tested with recent Win10 and Win11 and also found a Win10 1511 (and Slackware 1.1.2, Win3.1, OS/2, ...) in my VM image museum. Regardless of the exe manifest, RtlGetVersion and RtlGetNtVersionNumbers return the correct versions: 10.0.22621 (Win11 22H2) 10.0.19045 (Win10 22H2) 10.0.10586 (Win10 1511) Without a manifest, GetVersionEx returns: 6.2.9200 (Win8) Please check on commit 48511f3d3847c. It was a real, existing problem at the time. I wouldn't have added the RtlGetNtVersionNumbers call just for fun. Of course. I learned about the existence of RtlGetNtVersionNumbers via this commit and was curious, which Windows versions were affected but found none. This suggests that only some early Win10 versions were affected. -- Regards, Christian -- 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: GetVersionEx() depreciated, what should be used instead for Windows 7/8/10?
On Mar 21 16:15, Corinna Vinschen via Cygwin wrote: On Mar 21 09:58, Christian Franke via Cygwin wrote: .. I just gave it a try on W11. The results are even more funny than I anticipated: ... So, yeah, with your observations especially on older W10 versions and with 8.1 doing the same thing, I guess we can safely drop the extra call to RtlGetNtVersionNumbers now. Or: Keep RtlGetVersionNumbers, compare result with RtlGetVersion and emit debug output if both differ. This would allow to diagnose a possible future reappearance of the issue. After such a long time, I don't know on which version of Windows we observed the problem. Some developer preview? Meantime I also tested with Win10 1607, 1703, 1709, 1803 VM snapshots with same result. -- Regards, Christian -- 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: GetVersionEx() depreciated, what should be used instead for Windows 7/8/10?
Corinna Vinschen via Cygwin wrote: On Mar 23 10:57, Christian Franke via Cygwin wrote: On Mar 21 16:15, Corinna Vinschen via Cygwin wrote: On Mar 21 09:58, Christian Franke via Cygwin wrote: .. I just gave it a try on W11. The results are even more funny than I anticipated: ... So, yeah, with your observations especially on older W10 versions and with 8.1 doing the same thing, I guess we can safely drop the extra call to RtlGetNtVersionNumbers now. Or: Keep RtlGetVersionNumbers, compare result with RtlGetVersion and emit debug output if both differ. This would allow to diagnose a possible future reappearance of the issue. Good idea! Do you want to create a patch? I tried, but without success. Unfortunately debug_printf() does not work because wincap.init() is called before get_cygwin_startup_info() which calls strace.activate(). -- 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
util-linux-2.39.3-1: libblkid returns invalid physical_sector_size
Testcase:
# cygcheck -f /sbin/fdisk.exe
util-linux-2.39.3-1
# /sbin/fdisk.exe -l /dev/sdd
Disk /dev/sdd: 465.76 GiB, 500107862016 bytes, 976773168 sectors
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 34359738880 bytes
I/O size (minimum/optimal): 34359738880 bytes / 34359738880 bytes
Disklabel type: dos
Disk identifier: 0x0ac1a23
Device Boot Start End Sectors Size Id Type
/dev/sdd1 2048 976769023 976766976 465.8G 7 HPFS/NTFS/exFAT
Partition 1 does not start on physical sector boundary.
# printf '0x%016x\n' 34359738880
0x00080200
The problem is that libblkid expects the results of BLKIOMIN, BLKIOOPT
and BLKPBSZGET as 64 bit 'unsigned long' but Cygwin only returns 32 bit
'int':
- util-linux-2.39.3/libblkid/src/topology/ioctl.c:
...
static const struct topology_val {
long ioc;
/* functions to set probing result */
int (*set_ulong)(blkid_probe, unsigned long);
int (*set_int)(blkid_probe, int);
int (*set_u64)(blkid_probe, uint64_t);
} topology_vals[] = {
{ BLKALIGNOFF, NULL, blkid_topology_set_alignment_offset },
{ BLKIOMIN, blkid_topology_set_minimum_io_size },
{ BLKIOOPT, blkid_topology_set_optimal_io_size },
{ BLKPBSZGET, blkid_topology_set_physical_sector_size },
#ifdef BLKGETDISKSEQ
{ BLKGETDISKSEQ, .set_u64 = blkid_topology_set_diskseq },
#endif
/* we read BLKSSZGET in topology.c */
};
...
- util-linux-2.39.3/libblkid/src/topology/topology.c:
...
struct blkid_struct_topology {
unsigned long alignment_offset;
unsigned long minimum_io_size;
unsigned long optimal_io_size;
unsigned long logical_sector_size;
unsigned long physical_sector_size;
unsigned long dax;
uint64_t diskseq;
};
...
int blkid_topology_set_physical_sector_size(blkid_probe pr, unsigned
long val)
...
- newlib-cygwin/winsup/cygwin/fhandler/floppy.cc:
...
case BLKIOMIN:
debug_printf ("BLKIOMIN");
*(int *)buf = (int) bytes_per_sector;
break;
case BLKIOOPT:
debug_printf ("BLKIOOPT");
*(int *)buf = (int) bytes_per_sector;
break;
case BLKPBSZGET:
debug_printf ("BLKPBSZGET");
*(int *)buf = (int) bytes_per_sector;
break;
...
A quick fix which only works on LE platforms:
- util-linux-2.39.3/libblkid/src/topology/ioctl.c:
...
static int probe_ioctl_tp(blkid_probe pr,
...
union {
unsigned long ul;
int i;
uint64_t u64;
- } data;
+ } data = { 0 };
...
Downgrading to util-linux-2.33.3-3 does not help. The related code
differs, but has the same problem.
The fdisk variant in busybox-1.36.1-2 is not affected.
--
Regards,
Christian
--
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: util-linux-2.39.3-1: libblkid returns invalid physical_sector_size
Hi Mark, Mark Geisert via Cygwin wrote: Hi Christian, On 3/31/2024 1:11 AM, Christian Franke via Cygwin wrote: Testcase: # cygcheck -f /sbin/fdisk.exe util-linux-2.39.3-1 # /sbin/fdisk.exe -l /dev/sdd Disk /dev/sdd: 465.76 GiB, 500107862016 bytes, 976773168 sectors Units: sectors of 1 * 512 = 512 bytes Sector size (logical/physical): 512 bytes / 34359738880 bytes I/O size (minimum/optimal): 34359738880 bytes / 34359738880 bytes [...valuable investigation and patch suggestion elided...] Your suggested patch looks fine to me. I have added it to the patch deck for a new util-linux 2.39.3-2, which has just been uploaded. The patch allows fdisk.exe to report the three correct values in my limited testing. Thanks for the report and the patch! You're welcome. BTW, according to the Linux kernel sources, BLKPBSZGET etc return 'unsigned int' and not 'unsigned long' since first appearance in 2.6.32-rc3 (2009?): https://elixir.bootlin.com/linux/v2.6.32-rc3/source/block/ioctl.c#L276 https://elixir.bootlin.com/linux/v2.6.32-rc3/source/block/compat_ioctl.c#L743 https://elixir.bootlin.com/linux/v6.8.2/source/block/ioctl.c#L533 So I don't understand why the mentioned code would be correct for Linux. -- 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: util-linux-2.39.3-1: libblkid returns invalid physical_sector_size
Bruce Jerrick via Cygwin wrote: Downgrading to util-linux-2.33.3-3 does not help. The related code differs, but has the same problem. I take that back. The above should read "util-linux-2.33.1-3". But it was OK in util-linux-2.33.1-3 . Yes, this is correct. I possibly downgraded util-linux, but forgot libblkid1. -- 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: util-linux-2.39.3-1: libblkid returns invalid physical_sector_size
Christian Franke via Cygwin wrote: ,,, BTW, according to the Linux kernel sources, BLKPBSZGET etc return 'unsigned int' and not 'unsigned long' since first appearance in 2.6.32-rc3 (2009?): https://elixir.bootlin.com/linux/v2.6.32-rc3/source/block/ioctl.c#L276 https://elixir.bootlin.com/linux/v2.6.32-rc3/source/block/compat_ioctl.c#L743 https://elixir.bootlin.com/linux/v6.8.2/source/block/ioctl.c#L533 So I don't understand why the mentioned code would be correct for Linux. It is likely an upstream regression from an 1+ year old commit. I filed a GH issue: https://github.com/util-linux/util-linux/issues/2904 -- 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: Cygwin a bit slow
J M via Cygwin wrote: ... Specifically for this problem, I have investigated the problem and can be related to pipes and antivirus. Specifically while true do echo ABC | grep AAA done It makes the cpu of that antivirus go up. This is as expected because malware scanners hook into Win32 API's CreateProcess*() calls which are also used by the fork()/exec() emulation of Cygwin. Each run of 'grep' above uses at least two CreateProcess*() calls. This quick test shows how many 'date' commands could be run per second: $ while :; do date +%s; done | uniq -c ... 65 1712742865 <== Windows Defender off 66 1712742866 66 1712742867 64 1712742868 61 1712742869 51 1712742870 <== Windows Defender turned on 51 1712742871 49 1712742872 45 1712742873 53 1712742874 54 1712742875 ... The above could even slow down to 1-2 per second with certain malware scanners if expensive heuristics (which may also generate a lot of false positives, BTW) is enabled. So one problem is the lousy performance of CreateProcess*() calls. This is not Cygwin-specific but affects typical Cygwin use cases like shell scripts. Using bash builtins in the above example speeds it up to ~21000/second on the same very old box: $ while :; do printf '%(%s)T\n'; done | uniq -c -- Regards, Christian -- 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: cygwin 3.5.4-1: signal handling destroys 'long double' values
Takashi Yano via Cygwin wrote: Hi Brian, On Tue, 8 Oct 2024 10:37:14 -0600 Brian Inglis wrote: On 2024-10-08 10:14, Brian Inglis via Cygwin wrote: On 2024-10-08 05:20, Takashi Yano via Cygwin wrote: On Mon, 7 Oct 2024 15:11:52 +0200 Christian Franke wrote: $ gcc -o sigtest -O2 sigtest.c $ ./sigtest > out.txt (press ^C 42x :-) $ sort out.txt | uniq -c 3 x = 0x1.23456789p+0, y = -nan, d = -nan 6 x = 0x1.23456789p+0, y = 0x1.23456789p+0, d = -nan 33 x = 0x1.23456789p+0, y = 0x1.23456789p+0, d = 0x0p+0 The problem also occurs if compiled without -O2, but less often. No problem occurs if compiled with -DWORKS which suggests that only 'long double' is affected. Thanks for the report. I looked into this problem and might find the cause. It seems due to a bug of scripts/gendef. It generates signal handler caller (sigfe.s) which stores/restores the registers. In sigdelayed, control word is stored/restored by fnstcw/fldcw instruction, however, fninit instruction destroys some status registers in FPU (x87). I think we shold use fnstenv/fldenv rather than fnstcw/fldcw and fninit. However, I'm not familiar with x87 instructions, so I may overlook something. Could anyone expert of x87 instructions and sigfe stuff give some comments? AIUI x87 FP handling is outdated and mainly unused on current systems, as current systems do more and use more than the legacy x87 instructions and stack. See https://en.cppreference.com/w/c/numeric/fenv and related docs for more modern approaches. You would have to look into the AMD/Intel/IEEE docs for lower level details. This is basically what ISTR: https://beta.boost.org/doc/libs/1_82_0/libs/context/doc/html/context/rationale/x86_and_floating_point_env.html where legacy x87 and MMX registers are not used or preserved on x86_64/amd64, as SSE... instructions and XMM registers are used. Thanks for the advice. I read throuh the web pages and related documents and made a patch which uses fxsave/fxrstor and xsave/xrstror to cygwin-patc...@cygwin.com mailing list. https://cygwin.com/pipermail/cygwin-patches/2024q4/012804.html The patch fixes the testcases from my original post on a CPU with XSAFE support and also if usage of FXSAVE if forced by this hack: movl \$1,%eax cpuid - andl \$0x0400,%ecx # xsave available? + andl \$0x,%ecx # xsave available? jnz 1f -- Regards, Christian -- 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
cygwin 3.5.4-1: signal handling destroys 'long double' values
Recently I used 'stress-ng --class compute ...' which reported the
failure of the 'logmath clogl' test. It could be reproduced with this
loop which finishes after some random number of iterations:
$ while stress-ng --logmath 1 --logmath-method clogl -t 1; do echo OK; done
stress-ng: info: [6190] setting to a 1 sec run per stressor
...
stress-ng: info: [6190] successful run completed in 1.37 sec
OK
...
OK
stress-ng: info: [6198] setting to a 1 sec run per stressor
stress-ng: info: [6198] dispatching hogs: 1 logmath
stress-ng: fail: [6199] logmath: clogl does not match expected result
stress-ng: error: [6198] logmath: [6199] terminated with an error, exit
status=2 (stressor failed)
...
stress-ng: info: [6198] unsuccessful run completed in 1.37 sec
The value mismatch occurs at the very end when the test loop running
clogl() is hit by the signal indicating timeout.
A closer look shows that the problem could also be reproduced without
any external math function:
$ uname -r
3.5.4-1.x86_64
$ gcc --version
gcc (GCC) 12.4.0
...
$ cat sigtest.c
#include
#include
static volatile sig_atomic_t sigcnt;
static void sigint_handler(int sig)
{
(void)sig;
sigcnt++;
}
#ifndef WORKS
typedef long double float_type;
#define FMT "La"
#else
typedef double float_type;
#define FMT "a"
#endif
int main()
{
signal(SIGINT, sigint_handler);
volatile float_type x = 0x1.23456789p+0;
while (sigcnt < 42) {
volatile float_type y = x;
volatile float_type d = y - x;
if (d != 0.0)
printf("x = %" FMT ", y = %" FMT ", d = %" FMT "\n", x, y, d);
}
}
$ gcc -o sigtest -O2 sigtest.c
$ ./sigtest > out.txt
(press ^C 42x :-)
$ sort out.txt | uniq -c
3 x = 0x1.23456789p+0, y = -nan, d = -nan
6 x = 0x1.23456789p+0, y = 0x1.23456789p+0, d = -nan
33 x = 0x1.23456789p+0, y = 0x1.23456789p+0, d = 0x0p+0
The problem also occurs if compiled without -O2, but less often. No
problem occurs if compiled with -DWORKS which suggests that only 'long
double' is affected.
--
Regards,
Christian
--
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: Request for test by users seeing 0.00 load average in spite of a busy system
Mark Geisert via Cygwin wrote: Hi folks, I may have a handle on why you're seeing 0.00 load averages. Would you kindly compile the attached program, run it, and post its results along with which version of Windows you are running? For example, gcc -Wall -ggdb -o test test.c -lpdh ./test Thanks for your help, Same result on Win10 22H2 (10.0.19045.4780, i7-2600K) and Win11 23H2 (10.0.22631.4037, i7-14700K): $ ./test PdhOpenQueryW returns PDH_CSTATUS_VALID_DATA PdhAddEnglishCounterW#1 returns PDH_CSTATUS_VALID_DATA PdhAddEnglishCounterW#2 returns PDH_CSTATUS_VALID_DATA PdhAddEnglishCounterW#3 returns PDH_CSTATUS_VALID_DATA $ uname -r 3.5.4-1.x86_64 $ stress-ng --cpu 4 --timeout 30 stress-ng: info: [586] setting to a 30 secs run per stressor stress-ng: info: [586] dispatching hogs: 4 cpu ... stress-ng: info: [586] successful run completed in 30.47 secs $ uptime 09:59:01 up 28 min, 0 user, load average: 0.00, 0.00, 0.00 -- Regards, Christian -- 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: cygwin 3.5.4-1: signal handling destroys 'long double' values
Takashi Yano via Cygwin wrote: ... Please check v2 patch. The v3(!) patch fixes my testcases. Both branches (xsave64, fxsave64) were tested. -- Regards, Christian -- 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
cygwin 3.5.4-1: lockf() aborts on overlap and does not fail on overflow
Two possibly independent bugs found by 'stress-ng --lockf ...':
1) lockf() may abort the process with api_fatal() if the new range
partly overlaps with two ranges previously locked by the same process.
2) lockf() prints a warning on too many locks and returns success. It
should not print a warning and fail with ENOLCK instead.
Testcase for both:
$ uname -r
3.5.4-1.x86_64
$ cat locktest.c
#include
#include
#include
static int lock_at(int fd, int off, int size)
{
if (lseek(fd, off, SEEK_SET) < 0) {
perror("lseek"); return -1;
}
printf("\rlock %d-%d\n", off, off + size - 1); fflush(stdout);
if (lockf(fd, F_LOCK, size) < 0) {
perror("lock"); return -1;
}
return 0;
}
int main(int argc, char **argv)
{
int fd = open("locktest.tmp", O_RDWR|O_CREAT, 0666);
if (fd < 0) {
perror("open"); return 1;
}
if (argc == 1) {
lock_at(fd, 0, 2);
lock_at(fd, 2, 2);
lock_at(fd, 1, 2);
}
else {
for (int i = 0; i < 914; i++)
if (lock_at(fd, i, 1))
return 1;
}
printf("\rdone\n");
return 0;
}
$ gcc -o locktest locktest.c
$ ./locktest
lock 0-1
lock 2-3
lock 1-2
1 [main] locktest 44864 C:\cygwin64\tmp\locktest.exe: \
*** fatal error - NtCreateEvent(lock): 0xC035\
Hangup
$ ./locktest loop
lock 0-0
lock 1-1
lock 2-2
lock 3-3
...
lock 909-909
lock 910-910
lock 911-911
0 [main] locktest 44865 inode_t::get_all_locks_list: \
Warning, can't handle more than 910 locks per file.
lock 912-912
727 [main] locktest 44865 inode_t::get_all_locks_list: \
Warning, can't handle more than 910 locks per file.
lock 913-913
1329 [main] locktest 44865 inode_t::get_all_locks_list: \
Warning, can't handle more than 910 locks per file.
done
There is possibly also an off-by-one error as the 912'th lockf() prints
the first warning.
--
Regards,
Christian
--
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: Writing to '\\.\X:' that has no backing PhysicalDrive?
Ilya Basin via Cygwin wrote:
Hi.
I was trying to write an .img file to a VeraCrypt drive.
VeraCrypt doesn't create a virtual PhysicalDrive so tools like Rufus don't see
it.
I hoped that with cygwin I would be able to do that, but Cygwin only creates
/dev/sd?? nodes for PhysicalDrive partitions.
I tried `dd` with '\\.\X:', but it can't open for writing because it treats it
as a directory (reading succeeds).
$ dd count=1 if='\\.\E:' | xxd
1+0 records in
1+0 records out
512 bytes copied, 0.0213007 s, 24.0 kB/s
: eb52 904e 5446 5320 2020 2000 0208 .R.NTFS.
...
$ dd if=/dev/null count=0 of='\\.\E:'
dd: failed to open '\\.\E:': Is a directory
Could reproduce this. The inconsistency between open for reading vs.
writing of '\\.\E:' is actually interesting. Subtle bug in Cygwin?
Same error in MSYS2.
Does cygwin provide some (hidden) /dev/ nodes for drive letters or volumes like
"\\?\Volume{GUID}"? Can I create one with mknod?
Alternatively, VeraCrypt Volumes could be accessed via:
$ ls -l /proc/sys/DosDevices/E:
lr--r--r-- 1 ... /proc/sys/DosDevices/E: ->
/proc/sys/Device/VeraCryptVolumeE
But /proc/sys is completely R/O like /proc/registry, so you cannot write
the image via this path.
OT:
/proc/sys/Device/HarddiskVolumeShadowCopyN[/PATH/TO/FILE] allows to read
the image and individual files from a volume shadow copy.
--
Regards,
Christian
--
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: Writing to '\\.\X:' that has no backing PhysicalDrive?
Christian Franke via Cygwin wrote:
Ilya Basin via Cygwin wrote:
Hi.
I was trying to write an .img file to a VeraCrypt drive.
VeraCrypt doesn't create a virtual PhysicalDrive so tools like Rufus
don't see it.
I hoped that with cygwin I would be able to do that, but Cygwin only
creates /dev/sd?? nodes for PhysicalDrive partitions.
I tried `dd` with '\\.\X:', but it can't open for writing because it
treats it as a directory (reading succeeds).
$ dd count=1 if='\\.\E:' | xxd
1+0 records in
1+0 records out
512 bytes copied, 0.0213007 s, 24.0 kB/s
: eb52 904e 5446 5320 2020 2000 0208 .R.NTFS .
...
$ dd if=/dev/null count=0 of='\\.\E:'
dd: failed to open '\\.\E:': Is a directory
Could reproduce this. The inconsistency between open for reading vs.
writing of '\\.\E:' is actually interesting. Subtle bug in Cygwin?
'\\.\X:' is mapped to NT path '\??\X:' internally. It is (mis-?)detected
as a directory. Open for write then fails intentionally:
int
fhandler_base::open_fs (int flags, mode_t mode)
{
/* Unfortunately NT allows to open directories for writing, but that's
disallowed according to SUSv3. */
if (pc.isdir () && (flags & O_ACCMODE) != O_RDONLY)
{
set_errno (EISDIR);
return 0;
}
...
}
stat() apparently returns garbage (X: is a mount point of a 1MiB
VeraCrypt file with FAT FS):
$ stat '\\.\X:'
File: \\.\X:
Size: 140720951294304 Blocks: 1 IO Block: 65536 regular file
Device: 0,195 Inode: 264012044753263394 Links: 0
Access: (0644/-rw-r--r--) Uid: ( 1000/ franke) Gid: ( 513/ none)
Access: 1601-01-01 01:22:04.,'-((0,00 +0053
Modify: 1601-01-01 01:22:04.+0/+'-,00 +0053
Change: 1601-01-01 00:53:29.'''''--00 +0053
Birth: -
$ ls -l /proc/sys/DosDevices/X:
lr--r--r-- 1 ... /proc/sys/DosDevices/X: ->
/proc/sys/Device/VeraCryptVolumeX
--
Regards,
Christian
--
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
SIGKILL may no longer work after many SIGCONT/SIGSTOP signals
Found with 'stress-ng --cpu-sched' from current stress-ng upstream HEAD:
Testcase (attached):
$ gcc -O2 -o manysignals manysignals.c
$ ./manysignals
fork() = 1833
...
fork() = 1848
...
kill(1833, 17)
...
kill(1848, 17)
kill(1833, 9)
...
kill(1848, 9)
waitpid(1833, ., 0)
Run this in second terminal:
$ watch "ps | sed -n '1p;/manysignals/{/sed/d;p}'"
If 'S' appear in the first column, the child processes likely reached
the final SIGSTOP state. This takes some time. The parent process may
still hang in first waitpid() but should not.
If the parent process is aborted with ^C, child processes may be stopped
or left behind. Occasionally a child process that can not be stopped by
Cygwin (kill -9) is left behind.
Tested with ancient (i7-2600K) and more recent (i7-14700K) CPU :-)
Unrelated to the above, but related to 'stress-ng --cpu-sched' which
uses sched_get/setscheduler():
- sched_getscheduler() always returns SCHED_FIFO. As far as I understand
Linux sched(7), this is a non-preemptive real-time policy. The
preemptive SCHED_RR would possibly a more reasonable value.
Unfortunately SCHED_OTHER cannot be used because it would require to
ignore the priority.
- sched_setscheduler() always fails with ENOSYS. It IMO should allow to
set 'param->sched_priority' if 'policy' is equal to the value returned
by sched_getscheduler().
--
Regards,
Christian
#define _GNU_SOURCE
#include
#include
#include
#include
#include
static void xkill(pid_t pid, int sig)
{
printf("kill(%d, %d)\n", (int)pid, sig);
int ret = kill(pid, sig);
if (ret)
perror("kill");
}
int main()
{
// number of child processes
const int nprocs = 16;
// number of SIGSTOP+SIGCONT, ..., SIGSTOP+SIGCONT, SIGSTOP.
const int nstopcont = 10;
pid_t pids[nprocs];
for (int p = 0; p < nprocs; p++) {
pid_t pid = fork();
if (pid == (pid_t)-1) {
perror("fork"); return 1;
}
if (pid == 0) {
cpu_set_t cpus; CPU_ZERO(&cpus);
CPU_SET(0, &cpus);
if (sched_setaffinity(getpid(), sizeof(cpus), &cpus))
perror("setaffinity");
for (;;)
sched_yield();
}
printf("fork() = %d\n", (int)pid);
pids[p] = pid;
}
sleep(1);
for (int i = 0; ; ) {
for (int p = 0; p < nprocs; p++)
xkill(pids[p], SIGSTOP);
if (++i >= nstopcont)
break;
for (int p = 0; p < nprocs; p++)
xkill(pids[p], SIGCONT);
}
for (int p = 0; p < nprocs; p++)
xkill(pids[p], SIGKILL);
for (int p = 0; p < nprocs; p++) {
pid_t pid = pids[p];
printf("waitpid(%d, ., 0)\n", (int)pid); fflush(stdout);
int status;
pid_t ret = waitpid(pid, &status, 0);
if (ret == (pid_t)-1)
perror("waitpid");
}
return 0;
}
--
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: pread()/pwrite() fail with EBADF in child process if already used before fork()
Christian Franke via Cygwin wrote:
Found during test of 'stress-ng --pseek ...' from current upstream
stress-ng git HEAD:
Testcase:
$ uname -r
3.5.4-1.x86_64
$ cat pfail.c
#include
#include
#include
#include
int main()
{
int fd = open("pwrite.tmp", O_RDWR|O_CREAT|O_BINARY, 0666);
if (fd < 0) {
perror("open"); return 1;
}
char c = 42;
if (pwrite(fd, &c, 1, 0) < 0)
perror("pwrite");
if (fork() == 0) {
if (pread(fd, &c, 1, 0) < 0)
perror("pread");
_exit(0);
}
int status;
wait(&status);
return 0;
}
$ make pfail
cc pfail.c -o pfail
$ ./pfail
pread: Bad file descriptor
$ strace ./pfail
...
617 75356 [main] pfail 10826 dofork: 10827 = fork()
82 11289 [main] pfail 10827 seterrno_from_nt_status:
/usr/src/debug/cygwin-3.5.4-1/winsup/cygwin/fhandler/disk_file.cc:1883
status 0xC008 -> windows error 6
80 75436 [main] pfail 10826 wait4: calling proc_subproc, pid -1,
options 0
76 11365 [main] pfail 10827 geterrno_from_win_error: windows
error 6 == errno 9
78 75514 [main] pfail 10826 proc_subproc: args: 5, -7728
64 11429 [main] pfail 10827 pread: -1 = pread(3, 0x7CC0B, 1,
0), errno 9
...
The problem does not occur if there is no pread()/pwrite() before the
fork(). This suggests that the child process inherits the extra handle
value used to keep the original seek position, but not the actual handle.
The mentioned extra handle 'prw_handle' is set to null after fork here:
https://cygwin.com/git/?p=newlib-cygwin.git;a=blob;f=winsup/cygwin/fhandler/disk_file.cc;h=f4c21d3#l1698
But a test suggests that fhandler_disk_file::fixup_after_fork() is never
called or debug_printf() does not work if called in this function.
Thoughts?
--
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
pread()/pwrite() fail with EBADF in child process if already used before fork()
Found during test of 'stress-ng --pseek ...' from current upstream
stress-ng git HEAD:
Testcase:
$ uname -r
3.5.4-1.x86_64
$ cat pfail.c
#include
#include
#include
#include
int main()
{
int fd = open("pwrite.tmp", O_RDWR|O_CREAT|O_BINARY, 0666);
if (fd < 0) {
perror("open"); return 1;
}
char c = 42;
if (pwrite(fd, &c, 1, 0) < 0)
perror("pwrite");
if (fork() == 0) {
if (pread(fd, &c, 1, 0) < 0)
perror("pread");
_exit(0);
}
int status;
wait(&status);
return 0;
}
$ make pfail
cc pfail.c -o pfail
$ ./pfail
pread: Bad file descriptor
$ strace ./pfail
...
617 75356 [main] pfail 10826 dofork: 10827 = fork()
82 11289 [main] pfail 10827 seterrno_from_nt_status:
/usr/src/debug/cygwin-3.5.4-1/winsup/cygwin/fhandler/disk_file.cc:1883
status 0xC008 -> windows error 6
80 75436 [main] pfail 10826 wait4: calling proc_subproc, pid -1,
options 0
76 11365 [main] pfail 10827 geterrno_from_win_error: windows error
6 == errno 9
78 75514 [main] pfail 10826 proc_subproc: args: 5, -7728
64 11429 [main] pfail 10827 pread: -1 = pread(3, 0x7CC0B, 1,
0), errno 9
...
The problem does not occur if there is no pread()/pwrite() before the
fork(). This suggests that the child process inherits the extra handle
value used to keep the original seek position, but not the actual handle.
--
Regards,
Christian
--
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: pread()/pwrite() fail with EBADF in child process if already used before fork()
Christian Franke via Cygwin wrote:
Christian Franke via Cygwin wrote:
Found during test of 'stress-ng --pseek ...' from current upstream
stress-ng git HEAD:
Testcase:
$ uname -r
3.5.4-1.x86_64
$ cat pfail.c
#include
#include
#include
#include
int main()
{
int fd = open("pwrite.tmp", O_RDWR|O_CREAT|O_BINARY, 0666);
if (fd < 0) {
perror("open"); return 1;
}
char c = 42;
if (pwrite(fd, &c, 1, 0) < 0)
perror("pwrite");
if (fork() == 0) {
if (pread(fd, &c, 1, 0) < 0)
perror("pread");
_exit(0);
}
int status;
wait(&status);
return 0;
}
$ make pfail
cc pfail.c -o pfail
$ ./pfail
pread: Bad file descriptor
$ strace ./pfail
...
617 75356 [main] pfail 10826 dofork: 10827 = fork()
82 11289 [main] pfail 10827 seterrno_from_nt_status:
/usr/src/debug/cygwin-3.5.4-1/winsup/cygwin/fhandler/disk_file.cc:1883
status 0xC008 -> windows error 6
80 75436 [main] pfail 10826 wait4: calling proc_subproc, pid -1,
options 0
76 11365 [main] pfail 10827 geterrno_from_win_error: windows
error 6 == errno 9
78 75514 [main] pfail 10826 proc_subproc: args: 5, -7728
64 11429 [main] pfail 10827 pread: -1 = pread(3, 0x7CC0B, 1,
0), errno 9
...
The problem does not occur if there is no pread()/pwrite() before the
fork(). This suggests that the child process inherits the extra
handle value used to keep the original seek position, but not the
actual handle.
The mentioned extra handle 'prw_handle' is set to null after fork here:
https://cygwin.com/git/?p=newlib-cygwin.git;a=blob;f=winsup/cygwin/fhandler/disk_file.cc;h=f4c21d3#l1698
But a test suggests that fhandler_disk_file::fixup_after_fork() is
never called or debug_printf() does not work if called in this function.
Possible fix:
https://sourceware.org/pipermail/cygwin-patches/2024q3/012793.html
--
Regards,
Christian
--
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: readdir() returns inaccessible name if file was created with invalid UTF-8
Brian Inglis via Cygwin wrote: On 2024-09-19 07:27, Christian Franke via Cygwin wrote: Mark Liam Brown via Cygwin wrote: On Mon, Sep 16, 2024 at 11:51 AM Christian Franke via Cygwin wrote: Christian Franke via Cygwin wrote: Thomas Wolff via Cygwin wrote: Am 15.09.2024 um 20:15 schrieb Thomas Wolff via Cygwin: Am 15.09.2024 um 19:47 schrieb Christian Franke via Cygwin: If a file name contains an invalid (truncated) UTF-8 sequence, open() does not refuse to create the file. Later readdir() returns a different name which could not be used to access the file. Testcase with U+1F321 (Thermometer): $ uname -r 3.5.4-1.x86_64 $ printf $'\U0001F321' | od -A none -t x1 f0 9f 8c a1 $ touch 'file1-'$'\xf0\x9f\x8c\xa1''.ext' $ touch 'file2-'$'\xf0\x9f\x8c''.ext' $ touch 'file3-'$'\xf0\x9f\x8c' $ ls -1 ls: cannot access 'file2-.?ext': No such file or directory ls: cannot access 'file3-': No such file or directory 'file1-'$'\360\237\214\241''.ext' file2-.?ext file3- I don't reproduce this. Yes, sorry, the above 'ls' was actually aliased to 'ls --color=auto' which needs to call stat(). Plain 'ls' does not, so the errors do not occur then. While the file name gets mangled, all resulting file names are valid and listed: In file2 the sequence is turned into U+17B3 but exchanged with the dot. In file3 the same sequence is just dropped. $ ls -1|cat file1-🌡.ext file2-.ឳext file3- However, ls file2* fails, as does ls *. On the other hand, ls file3- fails too, so some mapping error occurs internally. Also, the files cannot be deleted from cygwin (need to use cmd). 'rm' using the original names works for file2-..., but not for file3-... $ rm -v 'file2-'$'\xf0\x9f\x8c''.ext' removed 'file2-'$'\360\237\214''.ext' $ rm -v 'file3-'$'\xf0\x9f\x8c' rm: cannot remove 'file3-'$'\360\237\214': No such file or directory Further tests suggest that the problem only occurs with: - incomplete 4 byte UTF-8 sequences (Unicode above 16 bit) - complete but invalid 3 byte UTF-8 sequences which encode the UTF-16 'high surrogate' range (0xD800..0xDBFF). Makes perfect sense, the Windows kernel uses UTF16 internally. Yes, but Cygwin does not provide consistent forward/reverse UTF-8 <-> UTF-16 mappings. This makes no sense: $ touch 'file-'$'\xed\xa0\x80''.ext' # creates L"file-\xD800.ext" on NTFS $ strace ls -F ... ... fhandler_disk_file::readdir: 0 = readdir(...) (L"file-\xD800.ext" > "file-\xE2\x9E\xB3.ext") ... ... stat_worker: -1 = (\??\C:\cygwin64\tmp\file-?.ext,...) ... ls: cannot access 'file-?.ext': No such file or directory file-?.ext $ rm -v 'file-'$'\xed\xa0\x80''.ext' removed 'file-'$'\355\240\200''.ext' The UTF-8 sequence returned by readdir() decodes to U+27B3 (White-Feathered Rightwards Arrow). This could be fixed by handling UTF-8 of the surrogate range similar to other invalid sequences: Map each invalid byte to unicode range U+FF80 to U+. This works as expected if the above UTF-8 sequence is truncated: $ touch 'file-'$'\xed\xa0''.ext' # creates L"file-\xF0ED\xF0A0.ext" on NTFS $ ls -F 'file-'$'\355\240''.ext' Surrogates halves are invalid for UTF-8 encoding; they should be first be encoded as a valid UTF-16 code point. The encoder should just fail if it encounters any invalid sequence! Handling surrogates or other invalid values as anything other than invalid turns the encoding into what has been called WTF-8 where W may be for Windows! ;^> :-) I guess the idea behind Cygwin's filename mapping was to emulate Linux behavior as far as possible. AFAICS, Linux accepts any nonempty byte string without slash as a plain filename and leaves the interpretation (UTF-8?) to the userland. Cygwin maps 0x20..0x7f and valid UTF-8 sequences to UTF-16. Control chars and bytes from invalid UTF-8 sequences are mapped to the U+F0xx range. It should handle UTF-8 sequences which lead to the surrogate range the same way but currently does not. -- 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: readdir() returns inaccessible name if file was created with invalid UTF-8
Mark Liam Brown via Cygwin wrote: On Mon, Sep 16, 2024 at 11:51 AM Christian Franke via Cygwin wrote: Christian Franke via Cygwin wrote: Thomas Wolff via Cygwin wrote: Am 15.09.2024 um 20:15 schrieb Thomas Wolff via Cygwin: Am 15.09.2024 um 19:47 schrieb Christian Franke via Cygwin: If a file name contains an invalid (truncated) UTF-8 sequence, open() does not refuse to create the file. Later readdir() returns a different name which could not be used to access the file. Testcase with U+1F321 (Thermometer): $ uname -r 3.5.4-1.x86_64 $ printf $'\U0001F321' | od -A none -t x1 f0 9f 8c a1 $ touch 'file1-'$'\xf0\x9f\x8c\xa1''.ext' $ touch 'file2-'$'\xf0\x9f\x8c''.ext' $ touch 'file3-'$'\xf0\x9f\x8c' $ ls -1 ls: cannot access 'file2-.?ext': No such file or directory ls: cannot access 'file3-': No such file or directory 'file1-'$'\360\237\214\241''.ext' file2-.?ext file3- I don't reproduce this. Yes, sorry, the above 'ls' was actually aliased to 'ls --color=auto' which needs to call stat(). Plain 'ls' does not, so the errors do not occur then. While the file name gets mangled, all resulting file names are valid and listed: In file2 the sequence is turned into U+17B3 but exchanged with the dot. In file3 the same sequence is just dropped. $ ls -1|cat file1-🌡.ext file2-.ឳext file3- However, ls file2* fails, as does ls *. On the other hand, ls file3- fails too, so some mapping error occurs internally. Also, the files cannot be deleted from cygwin (need to use cmd). 'rm' using the original names works for file2-..., but not for file3-... $ rm -v 'file2-'$'\xf0\x9f\x8c''.ext' removed 'file2-'$'\360\237\214''.ext' $ rm -v 'file3-'$'\xf0\x9f\x8c' rm: cannot remove 'file3-'$'\360\237\214': No such file or directory Further tests suggest that the problem only occurs with: - incomplete 4 byte UTF-8 sequences (Unicode above 16 bit) - complete but invalid 3 byte UTF-8 sequences which encode the UTF-16 'high surrogate' range (0xD800..0xDBFF). Makes perfect sense, the Windows kernel uses UTF16 internally. Yes, but Cygwin does not provide consistent forward/reverse UTF-8 <-> UTF-16 mappings. This makes no sense: $ touch 'file-'$'\xed\xa0\x80''.ext' # creates L"file-\xD800.ext" on NTFS $ strace ls -F ... ... fhandler_disk_file::readdir: 0 = readdir(...) (L"file-\xD800.ext" > "file-\xE2\x9E\xB3.ext") ... ... stat_worker: -1 = (\??\C:\cygwin64\tmp\file-?.ext,...) ... ls: cannot access 'file-?.ext': No such file or directory file-?.ext $ rm -v 'file-'$'\xed\xa0\x80''.ext' removed 'file-'$'\355\240\200''.ext' The UTF-8 sequence returned by readdir() decodes to U+27B3 (White-Feathered Rightwards Arrow). This could be fixed by handling UTF-8 of the surrogate range similar to other invalid sequences: Map each invalid byte to unicode range U+FF80 to U+. This works as expected if the above UTF-8 sequence is truncated: $ touch 'file-'$'\xed\xa0''.ext' # creates L"file-\xF0ED\xF0A0.ext" on NTFS $ ls -F 'file-'$'\355\240''.ext' -- Regards, Christian -- 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: cygwin 3.5.4-1: lockf() aborts on overlap and does not fail on overflow
Takashi Yano via Cygwin wrote:
On Mon, 14 Oct 2024 15:36:02 +0200
Christian Franke wrote:
Two possibly independent bugs found by 'stress-ng --lockf ...':
1) lockf() may abort the process with api_fatal() if the new range
partly overlaps with two ranges previously locked by the same process.
2) lockf() prints a warning on too many locks and returns success. It
should not print a warning and fail with ENOLCK instead.
Testcase for both:
$ uname -r
3.5.4-1.x86_64
$ cat locktest.c
#include
#include
#include
static int lock_at(int fd, int off, int size)
{
if (lseek(fd, off, SEEK_SET) < 0) {
perror("lseek"); return -1;
}
printf("\rlock %d-%d\n", off, off + size - 1); fflush(stdout);
if (lockf(fd, F_LOCK, size) < 0) {
perror("lock"); return -1;
}
return 0;
}
int main(int argc, char **argv)
{
int fd = open("locktest.tmp", O_RDWR|O_CREAT, 0666);
if (fd < 0) {
perror("open"); return 1;
}
if (argc == 1) {
lock_at(fd, 0, 2);
lock_at(fd, 2, 2);
lock_at(fd, 1, 2);
}
else {
for (int i = 0; i < 914; i++)
if (lock_at(fd, i, 1))
return 1;
}
printf("\rdone\n");
return 0;
}
$ gcc -o locktest locktest.c
$ ./locktest
lock 0-1
lock 2-3
lock 1-2
1 [main] locktest 44864 C:\cygwin64\tmp\locktest.exe: \
*** fatal error - NtCreateEvent(lock): 0xC035\
Hangup
$ ./locktest loop
lock 0-0
lock 1-1
lock 2-2
lock 3-3
...
lock 909-909
lock 910-910
lock 911-911
0 [main] locktest 44865 inode_t::get_all_locks_list: \
Warning, can't handle more than 910 locks per file.
lock 912-912
727 [main] locktest 44865 inode_t::get_all_locks_list: \
Warning, can't handle more than 910 locks per file.
lock 913-913
1329 [main] locktest 44865 inode_t::get_all_locks_list: \
Warning, can't handle more than 910 locks per file.
done
There is possibly also an off-by-one error as the 912'th lockf() prints
the first warning.
Thanks for the report.
I looked into the problems, and considered how to fix them.
Could you please try the experimental patch attached?
Works as expected with both 'locktest.exe' and 'stress-ng --lockf ...'.
--
Thanks,
Christian
--
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: Stable SIDs for "None"+'"Administrator" ?
Roland Mainz via Cygwin wrote:
On Sat, Nov 9, 2024 at 6:00 PM Corinna Vinschen via Cygwin
wrote:
On Nov 9 17:31, Roland Mainz via Cygwin wrote:
Does anyone know a list of SIDs which can be used to get the
user+group accounts for passwd entry "Adminstrator" and group entry
"None" ?
Our problem is that the actual account names vary with the system
locale, e.g. group entry "None" is "Kein" in "de_DE", "Aucun" in
fr_FR etc. ...
... so far we thought we fixed this by doing a lookup via SID, and
then remembering the localised name.
But: The SIDs are apparently not stable between Windows versions.
For example:
snip
# Windows Server 2022/en
$ getent group None
None:S-1-5-21-168624908-967194555-3343779530-513:197121:
# Windows Server 2019
$ getent group None
None:S-1-5-21-3286904461-66123-4220857270-513:197121
snip
They *are* stable in that they are
${Machine-SID}-513
And if there is no such list, would $ mkgroup | egrep
':S-1-5-21-.+-513:' # be a suitable workaround ?
No.
${AD-SID|-513 == "Domain Users"
I have not the faintest idea what the MS guys were thinking at the time,
calling the group "None". This is basically the equivalent of "Domain
Users" for local accounts on machines not being domain controller. A
useful name would have been "Local Users" or "Machine Users", but,
well, it is what it is.
The safe way to check the SID is to fetch the machine SID attach the RID
513, and check for equality.
How can I get the "machine SID", preferably using /usr/bin/getent,
/usr/bin/getconf or /proc ?
If domain info is excluded from mkgroup output, the one and only S-*-513
group should contain the machine SID:
$ sid=$(mkgroup -l | sed -n 's/[^:]*:\(S-[-0-9]*\)-513:.*$/\1/p')
$ test $(wc -l <<<"$sid") = 1 || echo 'My assumption was wrong :-)'
--
Regards,
Christian
--
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
Segfault in pthread_sigqueue() or sigtimewait()
After enabling the usage of pthread_sigqueue() in stress-ng, 'stress-ng
--pthread ...' occasionally reports that child processes failed with
SIGSEGV.
The problem is unrelated to the recent fix of the signature of
pthread_sigqueue():
https://cygwin.com/git/?p=newlib-cygwin.git;a=commit;h=1e8c92e
It could be reproduced with Cygwin 3.5.4-1 and with current 3.6.0 TEST
release if the signature is adjusted.
Testcase (attached):
$ gcc -O2 -o sigfault sigfault.c # Add -DBETA if compiling for a TEST
release
$ strace -o trace.log ./sigfault
pthread_create({0xa000188d0}, ...)=0
pthread_sigqueue(0xa000188d0, SIGUSR1, .)
sigtimedwait(...)=30 (errno=0)
...
sigtimedwait(...)=30 (errno=0)
pthread_sigqueue(0xa000188d0, SIGUSR1, .)=0
pthread_join(0xa000188d0, .)=0
pthread_create({0xa000188d0}, ...)=0
pthread_sigqueue(0xa000188d0, SIGUSR1, .)
sigtimedwait(...)=30 (errno=0)
pthread_sigqueue(0xa000188d0, SIGUSR1, .)=0
pthread_join(0xa000188d0, .)=0
pthread_create({0xa000188d0}, ...)=0
pthread_sigqueue(0xa000188d0, SIGUSR1, .)
Segmentation fault
$ cat trace.log
...
78 103937 [main] sigfault 2074 sig_send: Waiting for pack.wakeup 0x21C
80 104017 [sig] sigfault 2074 sigpacket::process: signal 30 processing
147 104164 [sigfault] sigfault 2074 __set_errno: int
sigwait_common(const sigset_t*, siginfo_t*, PLARGE_INTEGER):643 setting
errno 11
103 104267 [sig] sigfault 2074 sigpacket::process: signal 30, signal
handler 0x1
84 104351 [sigfault] sigfault 2074 sigwait_common: returning signal -1
81 104432 [sig] sigfault 2074 sigpacket::setup_handler: controlled
interrupt. stackptr 0x7FFDFE220, stack 0x7FFDFE218, stackptr[-1] 0x100401109
78 104510 [sig] sigfault 2074 proc_subproc: args: 4, 1
74 104584 [sig] sigfault 2074 proc_subproc: clear waiting threads
71 104655 [sig] sigfault 2074 proc_subproc: finished clearing
70 104725 [sig] sigfault 2074 proc_subproc: returning 1
125 104850 [sig] sigfault 2074 _cygtls::interrupt_setup: armed
signal_arrived 0x24C, signal 30
74 104924 [sig] sigfault 2074 sigpacket::setup_handler: signal 30
delivered
83 105007 [sigfault] sigfault 2074 set_process_mask_delta: oldmask
0, newmask 2000, deltamask 2000
--- Process 9568 (pid: 2074), exception c005 at 0001
80 105087 [sig] sigfault 2074 sigpacket::process: returning 1
--- Process 9568 (pid: 2074) thread 7320 exited with status 0xc005
--- Process 9568 (pid: 2074) thread 8928 exited with status 0xc005
--- Process 9568 (pid: 2074) thread 6792 exited with status 0xc005
--- Process 9568 (pid: 2074) thread 5020 exited with status 0xc005
--- Process 9568 thread 9020 exited with status 0xc005
--- Process 9568 exited with status 0xc005
I guess the problem occurs because pthread_sigqueue() is sometimes
issued after the thread function already returned. The thread pointer
should be valid until pthread_join() is called. Sorry if I missed something.
--
Regards,
Christian
#define _GNU_SOURCE
#include
#include
#include
static volatile char started, stop;
static void * threadfunc(void *arg)
{
(void)arg;
started = 1;
while (!stop)
sched_yield();
siginfo_t info = {0};
sigset_t mask; sigemptyset(&mask);
sigaddset(&mask, SIGUSR1);
struct timespec timeout;
timeout.tv_sec = 0; timeout.tv_nsec = 1000;
errno = 0;
int ret = sigtimedwait(&mask, &info, &timeout);
printf("sigtimedwait(...)=%d (errno=%d)\n", ret, errno); fflush(stdout);
return NULL;
}
int main()
{
signal(SIGUSR1, SIG_IGN);
for (int i = 0; i < 1000; i++) {
started = stop = 0;
pthread_t t = NULL;
int ret = pthread_create(&t, NULL, threadfunc, NULL);
printf("pthread_create({%p}, ...)=%d\n", t, ret); fflush(stdout);
if (ret)
return 1;
while (!started)
sched_yield();
stop = 1;
union sigval value = {0};
printf("pthread_sigqueue(%p, SIGUSR1, .)\n", t); fflush(stdout);
#ifdef BETA
ret = pthread_sigqueue(t, SIGUSR1, value);
#else
ret = pthread_sigqueue(&t, SIGUSR1, value);
#endif
printf("pthread_sigqueue(%p, SIGUSR1, .)=%d\n", t, ret); fflush(stdout);
if (ret)
return 1;
ret = pthread_join(t, NULL);
printf("pthread_join(%p, .)=%d\n", t, ret); fflush(stdout);
if (ret)
return 1;
}
printf("done\n");
return 0;
}
--
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
Request: please update subversion-perl for Perl 5.40
git-svn could no longer be installed because it depends on subversion-perl (1.14.2-1) which still requires perl 5.36. Fallback to perl 5.36 works on existing installations but fails on new ones because some former perl-* packages for perl 5.36 are no longer on the mirrors, at least perl-URI 5.28-1. -- Thanks, Christian -- 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: Cygwin command to bind new process to CPUs 3,4?
Cedric Blancher via Cygwin wrote: Good morning! Does Cycgwin have a command to bind a new process to a specific set of CPUs, e.g. bind /usr/bin/eatfrogs to CPU cores 3 and 4? $ taskset -c 3,4 /usr/bin/eatfrogs ... $ cygcheck -f /usr/bin/taskset util-linux-2.39.3-2 -- Regards, Christian -- 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: 2 SCHED_IDLE bugs in Cygwin 3.6
Cedric Blancher via Cygwin wrote: On Fri, 20 Dec 2024 at 07:36, Brian Inglis via Cygwin wrote: On 2024-12-19 14:08, René Berber via Cygwin wrote: On 12/19/2024 2:01 PM, Eliot Moss via Cygwin wrote: On 12/19/2024 1:43 PM, Cedric Blancher via Cygwin wrote: cygwin.git;a=commit;h=61c2f075cd55d4a52b4713383f75870c1e416923 added SCHED_IDLE support for Cygwin 3.6. It should work. ^^^ Cygwin should support it, but I wonder if chrt (in util-linux) has been updated in light of the change. Version 3.6 is not a release, so unless you're using a snapshot... The maintainer can flip Cygwin to test 3.6... and use that to build a test release of util-linux with Cygwin >= 3.6 as a dependency and make that test release available. So you say util-linux only needs to be recompiled? Yes, otherwise the options related to the newly added SCHED_* defines have no effect: util-linux-2.39.3/schedutils/chrt.c: int main(...) ... case 'b': #ifdef SCHED_BATCH ctl->policy = SCHED_BATCH; #endif break; ... case 'i': #ifdef SCHED_IDLE ctl->policy = SCHED_IDLE; #endif break; The 'chrt --help' output is misleading because it always advertises '-b, --batch', '-i, --idle', ... -- Regards, Christian -- 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: /bin/ls -l cannot handle printable Unicode characters outside the BMP ...
Cedric Blancher via Cygwin wrote: On Sat, 23 Nov 2024 at 11:44, Cedric Blancher wrote: Good morning! /bin/ls -l cannot handle printable Unicode characters outside the BMP Example using '𝒯' bash -c 'printf "\U0001D4AF\n"' # MATHEMATICAL SCRIPT CAPITAL T (yes, our mathematicians want to use THAT as file name) On Linux: LC_ALL=en_US.UTF-8 bash -c 't="$(printf "\U0001D4AF\n")" ; touch "$t" "$t$t"' ls -la total 8 -rw-r--r-- 1 ced staden 0 Nov 23 11:29 ööö -rw-r--r-- 2 ced staden 4 Nov 23 11:31 𝒯 -rw-r--r-- 2 ced staden 4 Nov 23 11:31𝒯𝒯 On Cygwin: LC_ALL=en_US.UTF-8 bash -c 't="$(printf "\U0001D4AF\n")" ; touch "$t" "$t$t"' $ ls -la -rw-r--r-- 1 ced staden 0 Nov 23 11:29 ööö -rw-r--r-- 2 ced staden 4 Nov 23 11:31 ''$'\360\235\222\257' -rw-r--r-- 2 ced staden 4 Nov 23 11:31 ''$'\360\235\222\257\360\235\222\257' Looks like the Cygwin locale has a problem with non-BMP chars. find(1) is even worse: $ find . . ./ööö ./ ./x??x The Microsoft Explorer GUI shows the file names correctly, so IMO this is not a Windows or Win32 API problem. Slightly different filename problem which may be related or not: https://sourceware.org/pipermail/cygwin/2024-September/256451.html -- Regards, Christian -- 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
Signals may be lost during setjmp or longjmp
The command 'stress-ng --longjmp ... -t 1' occasionally fails to
terminate because some child process does not receive the SIGALRM
indicating timeout.
Testcase (attached):
$ g++ -O2 -o longjmpsigs longjmpsigs.cc
$ ./longjmpsigs
[^C]
INT 1
[^C]
INT 2
...
[^C]
INT 21
[^C]
[^C]
INT 22
...
The following run in a second window may not stop the process due to few
lost signals:
for i in {1..100}; do
echo $i; killall -INT longjmpsigs || break; sleep 1
done
The problem does not occur if a regular loop is used instead of
setjmp/longjmp.
Reproducible also with current cygwin1.dll 26144e40.
--
Regards,
Christian
#include
#include
#include
#include
static volatile std::atomic_int sigcnt;
static void sigfunc(int) { sigcnt++; }
int main()
{
volatile int prev = 0;
signal(SIGINT, sigfunc);
jmp_buf jb; setjmp(jb); // loop:
volatile int cnt = sigcnt;
if (cnt > prev) {
printf("INT %3d\n", cnt);
if (cnt >= 100)
return 0;
prev = cnt;
}
longjmp(jb, 1); // goto loop;
}
--
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: SIGKILL may no longer work after many SIGCONT/SIGSTOP signals
Takashi Yano via Cygwin wrote:
On Wed, 20 Nov 2024 22:43:08 +0900
Takashi Yano wrote:
On Tue, 19 Nov 2024 18:21:52 +0900
Takashi Yano wrote:
On Tue, 12 Nov 2024 10:53:58 +0100
Christian Franke wrote:
Found with 'stress-ng --cpu-sched' from current stress-ng upstream HEAD:
Testcase (attached):
$ gcc -O2 -o manysignals manysignals.c
$ ./manysignals
fork() = 1833
...
fork() = 1848
...
kill(1833, 17)
...
kill(1848, 17)
kill(1833, 9)
...
kill(1848, 9)
waitpid(1833, ., 0)
Run this in second terminal:
$ watch "ps | sed -n '1p;/manysignals/{/sed/d;p}'"
If 'S' appear in the first column, the child processes likely reached
the final SIGSTOP state. This takes some time. The parent process may
still hang in first waitpid() but should not.
If the parent process is aborted with ^C, child processes may be stopped
or left behind. Occasionally a child process that can not be stopped by
Cygwin (kill -9) is left behind.
Tested with ancient (i7-2600K) and more recent (i7-14700K) CPU :-)
Unrelated to the above, but related to 'stress-ng --cpu-sched' which
uses sched_get/setscheduler():
- sched_getscheduler() always returns SCHED_FIFO. As far as I understand
Linux sched(7), this is a non-preemptive real-time policy. The
preemptive SCHED_RR would possibly a more reasonable value.
Unfortunately SCHED_OTHER cannot be used because it would require to
ignore the priority.
- sched_setscheduler() always fails with ENOSYS. It IMO should allow to
set 'param->sched_priority' if 'policy' is equal to the value returned
by sched_getscheduler().
Thanks for the report and the test case. I'm now looking into
the issue. Please wait a while.
Hopefully, I have found the cause.
The deadlock happens between main thread and wait_sig thread.
The main thread is waiting for the wait_sig thread triggering
wakeup event while the wait_sig thread is waiting previous
signal being processed by main thread.
Let me consider how to fix that.
I'd like to report my progress for this issue.
The patch attached almost solves the problem. ...
Compile error if applied to current git main (3dbc8c3):
../../../../winsup/cygwin/exceptions.cc:1487:21: error: struct
_cygtls has no member named sig
1487 | while (_main_tls->sig)
| ^~~
However, your test
case is paused for tens of seconds, then ends normally.
I guess this is as expected. The processing of the
SIGSTOP/SIGCONT/.../SIGSTOP/SIGKILL sequence of each child process take
some time because all are locked to a single core.
If the code:
cpu_set_t cpus; CPU_ZERO(&cpus);
CPU_SET(0, &cpus);
if (sched_setaffinity(getpid(), sizeof(cpus), &cpus))
perror("setaffinity");
for (;;)
sched_yield();
is changed to just:
for (;;) sleep(1);
the test case runs without pause.
The pause will possibly reappear if the number of child processes is
increased to some multiple of the available cores.
I think there still is a bug in the signal handling.
Possibly related:
https://sourceware.org/pipermail/cygwin/2024-November/256808.html
--
Regards,
Christian
--
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: cygwin 3.5.6-1
Corinna Vinschen via Cygwin-announce wrote:
The following packages have been uploaded to the Cygwin distribution:
* cygwin-3.5.6-1
* cygwin-devel-3.5.6-1
* cygwin-doc-3.5.6-1
Fixes:
--
...
- Fix mq_unlink().
Addresses: https://cygwin.com/pipermail/cygwin/2025-January/257119.html
Now mq_unlink("/queue") and unlink("/dev/mqueue/queue") work, thanks!
But there is a regression:
stat() now returns st_mode = 0 for the queue file which results in an
invalid S_IFMT field:
$ uname -r
3.5.6-1.x86_64
$ stat --printf '0x%04f/%A %n (%F)\n' /dev/mqueue /dev/mqueue/mqtest
0x43ff/drwxrwxrwt /dev/mqueue (directory)
0x/?- /dev/mqueue/mqtest (weird file)
$ rm -iv /dev/mqueue/mqtest
rm: remove write-protected weird file '/dev/mqueue/mqtest'? y
removed '/dev/mqueue/mqtest'
Previous:
$ uname -r
3.5.5-1.x86_64
$ stat --printf '0x%04f/%A %n (%F)\n' /dev/mqueue /dev/mqueue/mqtest
0x43ff/drwxrwxrwt /dev/mqueue (directory)
0x8180/-rw--- /dev/mqueue/mqtest (regular file)
$ rm -iv /dev/mqueue/mqtest
rm: remove regular file '/dev/mqueue/mqtest'? y
rm: cannot remove '/dev/mqueue/mqtest': Operation not permitted
--
Regards,
Christian
--
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: cygwin 3.5.6-1
Corinna Vinschen via Cygwin wrote:
On Jan 27 08:12, Christian Franke via Cygwin wrote:
Corinna Vinschen via Cygwin-announce wrote:
The following packages have been uploaded to the Cygwin distribution:
* cygwin-3.5.6-1
* cygwin-devel-3.5.6-1
* cygwin-doc-3.5.6-1
Fixes:
--
...
- Fix mq_unlink().
Addresses: https://cygwin.com/pipermail/cygwin/2025-January/257119.html
Now mq_unlink("/queue") and unlink("/dev/mqueue/queue") work, thanks!
But there is a regression:
stat() now returns st_mode = 0 for the queue file which results in an
invalid S_IFMT field:
$ uname -r
3.5.6-1.x86_64
$ stat --printf '0x%04f/%A %n (%F)\n' /dev/mqueue /dev/mqueue/mqtest
0x43ff/drwxrwxrwt /dev/mqueue (directory)
0x/?- /dev/mqueue/mqtest (weird file)
$ rm -iv /dev/mqueue/mqtest
rm: remove write-protected weird file '/dev/mqueue/mqtest'? y
removed '/dev/mqueue/mqtest'
Previous:
$ uname -r
3.5.5-1.x86_64
$ stat --printf '0x%04f/%A %n (%F)\n' /dev/mqueue /dev/mqueue/mqtest
0x43ff/drwxrwxrwt /dev/mqueue (directory)
0x8180/-rw--- /dev/mqueue/mqtest (regular file)
$ rm -iv /dev/mqueue/mqtest
rm: remove regular file '/dev/mqueue/mqtest'? y
rm: cannot remove '/dev/mqueue/mqtest': Operation not permitted
Oh well, I just pushed a patch to patch that patch. I made Cygwin treat
message queues as devices, but that was apparently over the top. I
reverted this to being treated as files again and just made sure the
check for being "anything with a representation on disk" is positive.
That in turn convinces unlink() to try removing them.
Please test cygwin-3.6.0-0.345.gb940faa144ca, which should be up in
an hour or so.
Looks good:
$ uname -r
3.6.0-0.345.gb940faa144ca.x86_64
$ rm -iv /dev/mqueue/mqtest
rm: cannot remove '/dev/mqueue/mqtest': No such file or directory
$ touch /dev/mqueue/mqtest
$ stat --printf '0x%04f/%A %n (%F)\n' /dev/mqueue /dev/mqueue/mqtest
0x43ff/drwxrwxrwt /dev/mqueue (directory)
0x81a4/-rw-r--r-- /dev/mqueue/mqtest (regular file)
$ cat /dev/mqueue/mqtest
QSIZE:0 NOTIFY:0 SIGNO:0 NOTIFY_PID:0
$ rm -iv /dev/mqueue/mqtest
rm: remove regular file '/dev/mqueue/mqtest'? y
removed '/dev/mqueue/mqtest'
Same behavior as on Linux.
--
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: mq_send()/mq_receive() may never return if used from threads
Christian Franke wrote: Found with 'stress-ng --workload ...': If mq_receive is called on an empty queue and mq_send is called later from a different thread, both functions never return and signals (including SIGKILL) are no longer processed. Testcase (attached): $ uname -r 3.5.5-1.x86_64 The problem is also reproducible with 3.5.6-1 and recent 3.6.0-0.345.gb940faa144ca $ gcc -o mqhang mqhang.c $ ./mqhang mq_send... mq_send = 0 mq_receive... mq_receive = 8 mq_receive... mq_send... [...hangs...] Problem does not occur if mq_receive() is called from a fork()ed process instead of a thread. -- Regards, Christian -- 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: mq_send()/mq_receive() may never return if used from threads
Corinna Vinschen via Cygwin wrote: On Jan 27 20:35, Corinna Vinschen via Cygwin wrote: On Jan 27 19:59, Christian Franke via Cygwin wrote: Christian Franke wrote: Found with 'stress-ng --workload ...': If mq_receive is called on an empty queue and mq_send is called later from a different thread, both functions never return and signals (including SIGKILL) are no longer processed. Testcase (attached): $ uname -r 3.5.5-1.x86_64 The problem is also reproducible with 3.5.6-1 and recent 3.6.0-0.345.gb940faa144ca Yes, because I didn't have the time to look into it yet. I just did, and I think I see what's going on. This should be fixed in 3.5.7. I just pushed a patch, please try cygwin-3.6.0-0.346.gfe6ddc15a356. $ uname -r 3.6.0-0.346.gfe6ddc15a356.x86_64 $ time ./mqhang mq_send... mq_send = 0 mq_receive... mq_receive = 8 mq_receive... mq_send... mq_receive = 8 mq_send = 0 real 0m5.002s user 0m0.000s sys 0m0.000s $ stress-ng --workload 16 --timeout 60 --verify stress-ng: info: [4873] setting to a 1 min run per stressor stress-ng: info: [4873] dispatching hogs: 16 workload stress-ng: info: [4874] workload: running with 2 threads per stressor instance stress-ng: info: [4873] skipped: 0 stress-ng: info: [4873] passed: 16: workload (16) stress-ng: info: [4873] failed: 0 stress-ng: info: [4873] metrics untrustworthy: 0 stress-ng: info: [4873] successful run completed in 1 min, 3.31 secs Looks good! Thanks, Christian -- 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
mq_send(-1, ...) segfaults instead of failing with EBADF
Found with 'stress-ng --mq 1 -v':
If an invalid fd is passed to mq_send() and other mq_* functions, a
segfault occurs instead of returning -1 with errno=EBADF. Depending on
optimization, the segfault is not visible in the exit status.
Testcase:
$ uname -r
3.5.5-1.x86_64
$ gcc --version
gcc (GCC) 12.4.0
...
$ cat mqbadfd.c
#include
#include
int main()
{
printf("mq_send:\n"); fflush(stdout);
int ret = mq_send(-1, "FOO", 3, 1);
printf("ret = %d\n", ret); fflush(stdout);
return 42;
}
$ gcc -o mqbadfd mqbadfd.c
$ ./mqbadfd; echo $?
mq_send:
0
$ gcc -o mqbadfd2 -O2 mqbadfd.c
$ ./mqbadfd2; echo $?
mq_send:
Segmentation fault
139
$ strace ./mqbadfd
...
111 49460 [main] mqbadfd 23013 fhandler_console::write: 9 =
fhandler_console::write(...)
39 49499 [main] mqbadfd 23013 write: 9 = write(1, 0xA00017790, 9)
211 49710 [main] mqbadfd 23013 __set_errno:
cygheap_fdget::cygheap_fdget(int, bool, bool):631 setting errno 9
--- Process 15116 (pid: 23013), exception c005 at 7ffc766fc71e
--- Process 15116 (pid: 23013) thread 4672 exited with status 0xc005
--- Process 15116 thread 12184 exited with status 0xc005
--- Process 15116 thread 16828 exited with status 0xc005
--- Process 15116 thread 16892 exited with status 0xc005
--- Process 15116 exited with status 0xc005
Segmentation fault
$ strace ./mqbadfd2
...
170 22096 [main] mqbadfd2 23017 write: 9 = write(1, 0xA00017790, 9)
71 22167 [main] mqbadfd2 23017 __set_errno:
cygheap_fdget::cygheap_fdget(int, bool, bool):631 setting errno 9
--- Process 13872 (pid: 23017), exception c005 at 7ffc766fc71e
58 5 [main] mqbadfd2 23017 exception::handle: In
cygwin_except_handler exception 0xC005 at 0x7FFC766FC71E sp 0x7CB30
25 22250 [main] mqbadfd2 23017 exception::handle: In
cygwin_except_handler signal 11 at 0x7FFC766FC71E
38 22288 [main] mqbadfd2 23017 break_here: break here
--- Process 13872 (pid: 23017), exception c005 at 7ffc766fc71e
--- Process 13872 (pid: 23017), exception c005 at 7ffc766fc71e
--- Process 13872 (pid: 23017), exception c005 at 7ffc766fc71e
--- Process 13872 (pid: 23017), exception c005 at 7ffc766fc71e
... [infinite loop - strace needs to be terminated by task manager]
Same if -fstack-protector-strong is added.
--
Regards,
Christian
--
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
mq_unlink() always fails with EPERM
mq_unlink() does not unlink anything and always returns -1 with errno =
EPERM.
Testcase:
$ uname -r
3.5.5-1.x86_64
$ cat mqunlink.c
#include
#include
#include
int main()
{
const char mq_name[] = "/mqtest";
const struct mq_attr attr = { 0, 10, 42, 0 };
mqd_t mq = mq_open(mq_name, O_RDWR | O_CREAT | O_EXCL, S_IRUSR |
S_IWUSR, &attr);
if (mq == (mqd_t)-1) {
perror("mq_open"); return 1;
}
mq_close(mq);
if (mq_unlink(mq_name)) {
perror("mq_unlink"); return 1;
}
return 0;
}
$ gcc -o mqunlink mqunlink.c
$ ./mqunlink
mq_unlink: Operation not permitted
$ ./mqunlink
mq_open: File exists
$ ls /dev/mqueue/
mqtest
$ rm /dev/mqueue/mqtest # Works on Linux
rm: cannot remove '/dev/mqueue/mqtest': Operation not permitted
$ cmd /c del 'C:\cygwin64\dev\mqueue\mqtest'
...
$ strace ./mqunlink
...
49 50005 [main] mqunlink 17288 __set_errno: int unlink(const
char*):1141 setting errno 1
48 50053 [main] mqunlink 17288 unlink: -1 =
unlink(/dev/mqueue/mqtest), errno 1
...
mq_unlink: Operation not permitted
--
Regards,
Christian
--
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
mq_send()/mq_receive() may never return if used from threads
Found with 'stress-ng --workload ...':
If mq_receive is called on an empty queue and mq_send is called later
from a different thread, both functions never return and signals
(including SIGKILL) are no longer processed.
Testcase (attached):
$ uname -r
3.5.5-1.x86_64
$ gcc -o mqhang mqhang.c
$ ./mqhang
mq_send...
mq_send = 0
mq_receive...
mq_receive = 8
mq_receive...
mq_send...
[...hangs...]
Problem does not occur if mq_receive() is called from a fork()ed process
instead of a thread.
--
Regards,
Christian
#include
#include
#include
#include
#include
static void *receiver(void *arg)
{
mqd_t mq = *(mqd_t*)arg;
unsigned prio;
char msg[42];
for (int i = 0; i < 2; i++) {
if (i == 0)
sleep(2);
printf("mq_receive...\n"); fflush(stdout);
ssize_t ret = mq_receive(mq, msg, sizeof(msg), &prio);
printf("mq_receive = %zd\n", ret); fflush(stdout);
}
return NULL;
}
int main()
{
const char mq_name[] = "/mqtest";
struct mq_attr attr = { 0, 10, 42, 0 };
mqd_t mq = mq_open(mq_name, O_CREAT | O_RDWR, S_IRUSR | S_IWUSR, &attr);
if (mq == (mqd_t)-1) {
perror("mq_open"); return 1;
}
pthread_t t;
if (pthread_create(&t, NULL, receiver, &mq)) {
fprintf(stderr, "pthread_create failed\n"); return 1;
}
const char msg[] = "Message";
for (int i = 0; i < 2; i++) {
if (i == 1)
sleep(5);
printf("mq_send...\n"); fflush(stdout);
int ret = mq_send(mq, msg, sizeof(msg), 0);
printf("mq_send = %d\n", ret); fflush(stdout);
}
pthread_join(t, NULL);
mq_close(mq);
mq_unlink(mq_name); // Fails, see separate post
return 0;
}
--
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: Cygwin 3.6 /usr/bin/cp from "coreutils" version 9.5-1 stuck in an endless loop...
On Tue, Jan 14, 2025, Roland Mainz via Cygwin wrote:
On Tue, Jan 14, 2025 at 7:19 AM Brian Inglis via Cygwin
wrote:
On 2025-01-13 13:10, Roland Mainz via Cygwin wrote:
I just hit an endless loop with /usr/bin/cp from "coreutils" version
9.5-1 copying a larger *.pdb file (it seems that only this specific
file is affected...) from Visual Studio 19.
Using strace -p $pid_of_cp I get this output:
snip
...
212 11917852 [main] cp 1319 fhandler_base::lseek: setting file
pointer to 1708032
200 11918052 [main] cp 1319 lseek: 1708032 = lseek(4, 1708032, 3)
239 11918291 [main] cp 1319 fhandler_base::lseek: setting file
pointer to 1708032
266 11918557 [main] cp 1319 lseek: 1708032 = lseek(4, 1708032, 4)
160 11918717 [main] cp 1319 fhandler_base::lseek: setting file
pointer to 1708032
[snip]
...
snip
This never stops, even after a couple of hours, but cp(1) can be
killed with
Downgrading to "coreutils" version 9.0-1 fixes the problem.
Cygwin version itself is
"CYGWIN_NT-10.0-19045 chickenmonster 3.6.0-0.304.g264544bf72f6.x86_64 2025-01-13
10:15 UTC x86_64 Cygwin"
The command is not simply looping, it is repeating 4 SEEK_HOLE, 0 SEEK_SET, 3
SEEK_DATA, at the same file offset, which looks like some kind of retry cycle,
but each of the operations are succeeding.
What is the exact command you are running and what are the source and target
filesystems?
...
I think I found the problem:
The *.pdb file uses NTFS compression:
snip
/bin/winfsinfo filebasicinfo "$(cygpath -w
$PWD/../build.vc19/x64/Debug/nfs41_driver.pdb)"
(
...
typeset -a FileAttributes=(
FILE_ATTRIBUTE_ARCHIVE
FILE_ATTRIBUTE_COMPRESSED
)
)
snip
If I remove the "FILE_ATTRIBUTE_COMPRESSED" flag /bin/cp works without problems.
I think the issues here are:
1. Coreutils 9.5-1 /bin/cp erroneously assumes that a file is sparse
if the number of blocks is smaller than $((filesize / fs_blocksize)) -
but in this case the file is NOT sparse, just compressed.
2. The loop to copy a sparse file is faulty because there are no holes
in that file. That itself is IMHO already a bad idea to have a
separate codepath for sparse files, just the normal codepath should
use SEEK_HOLE and just skip those in the destination
The infinite loop occurs because SEEK_DATA behaves different from Linux
and POSIX, see:
https://sourceware.org/pipermail/cygwin/2025-February/257330.html
--
Regards,
Christian
--
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
coreutils-9.0-1: chmod -R silently returns failure if dir contains a symlink (regression)
Testcase: $ uname -r 3.5.7-1.x86_64 $ cygcheck -f /bin/chmod coreutils-9.0-1 $ mkdir dir $ touch dir/file $ chmod -R -v g-w dir; echo $? mode of 'dir' retained as 0755 (rwxr-xr-x) mode of 'dir/file' retained as 0644 (rw-r--r--) 0 $ ln -s file dir/link $ chmod -R -v g-w dir; echo $? mode of 'dir' retained as 0755 (rwxr-xr-x) mode of 'dir/file' retained as 0644 (rw-r--r--) neither symbolic link 'dir/link' nor referent has been changed 1 $ chmod -R g-w dir; echo $? 1 $ chmod -v g-w dir dir/file dir/link; echo $? mode of 'dir' retained as 0755 (rwxr-xr-x) mode of 'dir/file' retained as 0644 (rw-r--r--) mode of 'dir/link' retained as 0644 (rw-r--r--) 0 $ chmod -R -v g+w dir; echo $? mode of 'dir' changed from 0755 (rwxr-xr-x) to 0775 (rwxrwxr-x) mode of 'dir/file' changed from 0644 (rw-r--r--) to 0664 (rw-rw-r--) neither symbolic link 'dir/link' nor referent has been changed 1 $ chmod -R g-w dir; echo $? 1 Exit status 1 does not occur with chmod from coreutils 8.32-1. -- Regards, Christian -- 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: List of packages installed by Cygwin setup.exe by default?
Marco Atzeri via Cygwin wrote:
On 08/02/2025 16:37, Martin Wege via Cygwin wrote:
Hello!
Is there a list of packages (including all their dependencies!) which
are installed by Cygwin setup.exe by default, e.g. start installer,
click everything "yes", but do not select any extra packages?
Thanks,
Martin
Look at the setup.ini content
Category: Base
There are few dependencies, not in base, that are fundamental libraries
e.g for Bash
---
@ bash
sdesc: "The GNU Bourne Again SHell"
..
category: Base Shells
..
depends2: cygwin, libiconv2, libintl8, libreadline7
...
--
Another method which also resolves the dependencies:
Start setup with "--no-write-registry" option, enter some new path as
"Root Directory" (it will be created but not written to registry),
proceed as usual until "Review and confirm changes" dialog, copy the
list from its textbox, abort setup and remove the newly created root
directory.
The current list:
Install _autorebase 001091-1
Install alternatives 1.31-1
Install base-cygwin 3.8-2
Install base-files 4.3-3
Install bash 5.2.21-1
Install bzip2 1.0.8-1
Install ca-certificates 2024.2.69_v8.0.401-1
Install coreutils 9.0-1
Install crypto-policies 20190218-1
Install cygutils 1.4.17-1
Install cygwin 3.5.7-1
Install dash 0.5.12-5
Install diffutils 3.10-1
Install editrights 1.04-1
Install file 5.44-1
Install findutils 4.10.0-1
Install gawk 5.3.0-1
Install getent 2.18.90-5
Install grep 3.11-1
Install groff 1.23.0-1
Install gzip 1.13-1
Install hostname 3.13-1
Install info 7.1-2
Install ipc-utils 1.1-1
Install less 668-1
Install libargp 20230708-2
Install libattr1 2.5.1-1.20.g0981a7bfe487
Install libblkid1 2.40.2-2
Install libbz2_1 1.0.8-1
Install libfdisk1 2.40.2-2
Install libffi6 3.2.1-2
Install libgcc1 12.4.0-3
Install libgdbm6 1.24-1
Install libgmp10 6.3.0-1
Install libiconv2 1.17-1
Install libintl8 0.22.5-1
Install liblastlog2 2.40.2-2
Install liblz4_1 1.9.4-1
Install liblzma5 5.6.4-1
Install libmpfr6 4.2.1-1
Install libncursesw10 6.5+20240427-1
Install libp11-kit0 0.23.20-1
Install libpcre1 8.45-1
Install libpcre2_8_0 10.44-1
Install libpipeline1 1.5.6-1
Install libpopt-common 1.19-1
Install libpopt0 1.19-1
Install libreadline7 8.2-2
Install libsmartcols1 2.40.2-2
Install libsqlite3_0 3.34.0-1
Install libssl1.1 1.1.1w-1
Install libssl3 3.0.15-1
Install libstdc++6 12.4.0-3
Install libtasn1_6 4.14-1
Install libuchardet0 0.0.8-1
Install libuuid1 2.40.2-2
Install libzstd1 1.5.6-1
Install login 1.13-1
Install man-db 2.13.0-1
Install mintty 3.7.7-1
Install ncurses 6.5+20240427-1
Install openssl 3.0.15-1
Install p11-kit 0.23.20-1
Install p11-kit-trust 0.23.20-1
Install rebase 4.6.6-1
Install run 1.3.4-2
Install sed 4.9-1
Install tar 1.35-2
Install terminfo 6.5+20240427-1
Install tzcode 2025a-1
Install tzdata 2025a-1
Install util-linux 2.40.2-2
Install vim-minimal 9.1.1054-1
Install which 2.20-2
Install xz 5.6.4-1
Install zlib0 1.3.1-1
Install zstd 1.5.6-1
BTW, the current disk space used by the above packages (4992 files, 581
directories):
148 MiB without compression,
93 MiB with NTFS compression (may result in significant file fragmentation),
63 MiB with Compact OS LZX compression ("--compact-os lzx" setup option).
--
Regards,
Christian
--
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: /bin/cp of sparse files broken in 3.6.0-0.362.g68c13dc92f65.x86_64?
Corinna Vinschen via Cygwin wrote: On Feb 15 11:17, Corinna Vinschen via Cygwin wrote: https://cygwin.com/cygwin-ug-net/using.html#cygdrive I uploaded the new 3.6 version of that chapter to cygwin.com, btw. BTW, the info "sparse ... This flag is always silently enabled on SSD drives" is only here: https://cygwin.com/cygwin-ug-net/mount.html but not here: https://cygwin.com/cygwin-ug-net/using.html#mount-table Note that, thanks to Cygwin's support of FALLOC_FL_PUNCH_HOLE, sparse files may also be created on non-sparse mounts if 'cp --sparse=always' is used. In some use cases requiring only single sparse files (e.g. create disk images with dd or ddrescue), it is also possible to preset the sparse attribute. Examples (on HDD): $ uname -r 3.6.0-0.374.g4dd859d01c22.x86_64 $ cp --version cp (GNU coreutils) 9.6 Packaged by Cygwin (9.6-1) ... $ dd if=/dev/zero bs=1M count=1 >file; echo EOF >>file $ cp file file-cp $ cp --sparse=always file file-cp-sparse-always $ dd if=file conv=sparse of=file-dd ... $ >file-dd-chattr-sparse $ chattr +S file-dd-chattr-sparse $ dd if=file conv=sparse,notrunc of=file-dd-chattr-sparse ... $ lsattr file* ---a-- file ---a-- file-cp ---a-S file-cp-sparse-always ---a-- file-dd ---a-S file-dd-chattr-sparse $ stat -c "%5b %s %n" file* 1028 1048580 file 1028 1048580 file-cp 64 1048580 file-cp-sparse-always 1028 1048580 file-dd 64 1048580 file-dd-chattr-sparse On a SSD, 'file-dd' would also be sparse. -- Regards, Christian -- 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: SEEK_DATA should fail at EOF (was: coreutils-9.6-1 (TEST): cp: infinite SEEK_SET/DATA/HOLE loop if file is compressed)
Corinna Vinschen via Cygwin wrote:
On Feb 14 14:14, Corinna Vinschen via Cygwin wrote:
On Feb 14 13:49, Corinna Vinschen via Cygwin wrote:
On Feb 14 12:24, Christian Franke via Cygwin wrote:
Hmm... does "beyond" mean '>=' or '>' ?
...do you think this fixes it?
diff --git a/winsup/cygwin/fhandler/base.cc b/winsup/cygwin/fhandler/base.cc
index 8f3dbd4ed51a..79dfaaa5987a 100644
--- a/winsup/cygwin/fhandler/base.cc
+++ b/winsup/cygwin/fhandler/base.cc
@@ -1144,7 +1144,7 @@ fhandler_base::lseek (off_t offset, int whence)
return -1;
}
/* Per Linux man page, ENXIO if offset is beyond EOF */
- if (offset > fsi.EndOfFile.QuadPart)
+ if (offset >= fsi.EndOfFile.QuadPart)
{
set_errno (ENXIO);
return -1;
Yeah, it does. I'll push the patch.
Patch is in the latest cygwin-3.6.0-0.373.gfac7441835b0
test release.
We're probably releasing 3.6 in the next few weeks.
Problem does not longer occur with 3.6.0-0.374.g4dd859d01c22.x86_64 and
cp from coreutils-9.6-1.
--
Problem reports: https://cygwin.com/problems.html
FAQ: https://cygwin.com/faq/
Documentation:https://cygwin.com/docs.html
Unsubscribe info: https://cygwin.com/ml/#unsubscribe-simple
STATUS_HEAP_CORRUPTION if signal arrives when x86 direction flag is set
Found because 'stress-ng --memcpy ...' and other tests report segfaults:
An exception 0xc374 (STATUS_HEAP_CORRUPTION) occurs if a signal
arrives during a memmove() which copies backwards due to overlap.
The related snippet[s] from winsup/cygwin/x86_64/bcopy.S:
std
rep
movs[qb]
cld
The testcase below shows that a set DF arrives at the signal handler.
This violates the ABI, AFAIK. After return, the process aborts
regardless of a "cld" in the signal handler.
$ uname -r # also reproducible with 3.5.7-1
3.6.0-1.x86_64
$ cat dflagsig.c
#include
#include
static volatile sig_atomic_t sigcnt;
static void sighandler(int sig)
{
(void)sig;
// asm volatile ("cld"); // <== does not prevent crash
if (__builtin_ia32_readeflags_u64() & 0x0400)
write(1, "[DF=1]\n", 7);
else
write(1, "[DF=0]\n", 7);
++sigcnt;
}
int main()
{
signal(SIGINT, sighandler);
int std = 0, cnt;
while ((cnt = sigcnt) < 5) {
if (cnt == 2 && !std) {
asm volatile ("std");
std = 1;
}
else if (cnt > 2 && std) {
asm volatile ("cld");
std = 0;
}
}
return 42;
}
$ gcc -o dflagsig dflagsig.c
$ ./dflagsig # ... and press 3x ^C
[DF=0]
[DF=0]
[DF=1]
$ echo $? # Hmm... "silent" crash!
0
$ strace ./dflagsig # ... and run 3x 'kill -INT 1288' from other window
...
48 14882485 [main] dflagsig 1288 set_signal_mask: setmask 2, newmask
0, mask_bits 2
863030 15745515 [sig] dflagsig 1288 sigpacket::process: signal 2 processing
...
55 15746773 [sig] dflagsig 1288 _cygtls::interrupt_setup: armed
signal_arrived 0x0, signal 2
70 15746843 [sig] dflagsig 1288 sigpacket::setup_handler: signal 2
delivered
--- Process 12736 (pid: 1288), exception c374 at 7ffe342dcba9
...
--- Process 12736 exited with status 0xc374
--
Regards,
Christian
--
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
Hang or crash after multiple SIGILL or SIGSEGV and siglongjmp
Found because 'stress-ng --priv-instr ...' hangs and then requires
'/bin/kill --force ...':
Testcase with
[PATCH v2] Cygwin: signal: Copy context to alternate stack in the
SA_ONSTACK case
already applied:
$ uname -r
3.7.0-dev-16-g2ef1a37e7823-dirty.x86_64
$ cat loopsigill.c
#include
#include
#include
#include
static volatile sig_atomic_t sigcnt;
static sigjmp_buf sjb;
static void sighandler(int sig)
{
(void)sig;
++sigcnt;
siglongjmp(sjb, 1);
write(1, "[FAIL]\n", 7);
}
int main()
{
signal(SIGILL, sighandler);
printf("pid=%d\n", (int)getpid());
while (sigsetjmp(sjb, 1))
;
// loop:
if (sigcnt < 10 || !(sigcnt % 1000))
printf("%06d\n", sigcnt);
if (sigcnt >= 10)
return 42;
asm volatile ("invd"); // goto loop;
return 13; // NOT REACHED
}
$ gcc -o loopsigill loopsigill.c
$ ./loopsigill # may succeed ...
pid=122
00
01
...
099000
10
$ echo $?
42
$ ./loopsigill # ... or crash silently ...
pid=130
00
01
...
026000
027000
$ echo $?
0
$ ./loopsigill # ... or hang
pid=135
00
01
...
037000
038000
[requires '/bin/kill --force ...']
$ strace -o trace.log ./loopsigill # run '/bin/kill --force ...' ASAP!
pid=142
00
[always hangs after first signal and fills trace.log quickly]
$ less trace.log
...
25 25501 [main] loopsigill 142 write: 7 = write(1, 0xA00017710, 7)
--- Process 6856 (pid: 142), exception c096 at 0001004011b9
142 25643 [main] loopsigill 142 exception::handle: In
cygwin_except_handler exception 0xC096 at 0x1004011B9 sp 0x7CBE0
26 25669 [main] loopsigill 142 exception::handle: In
cygwin_except_handler signal 4 at 0x1004011B9
38 25707 [main] loopsigill 142 break_here: break here
--- Process 6856 (pid: 142), exception c096 at 0001004011b9
--- Process 6856 (pid: 142), exception c096 at 0001004011b9
... likely repeated until disk is full or time_t wraps around...
--- Process 6856 (pid: 142), exception c096 at 0001004011b9
Problem also occurs
- without the mentioned patch,
- with get/setcontext() instead of sig*jmp(),
- with nullptr access and SIGSEGV handler,
- with Cygwin 3.5.7-1.
I agree that this is not a common use case :-)
--
Regards,
Christian
--
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: ftruncate() may fail with EISDIR if other process calls open()
Corinna Vinschen via Cygwin wrote:
On Apr 8 13:50, Corinna Vinschen via Cygwin wrote:
On Apr 7 09:59, Christian Franke via Cygwin wrote:
Found because 'stress-ng --fcntl 2 --verify' reports "ftruncate failed,
errno=21":
Thanks for the testcase. I know what happens. Stay tuned for a patch.
Nice problem. That's what happens if you try to do what an OS is doing,
without actually being an OS, just a user space lib. Theoretically we
should never cache any file information but always call the matching OS
functions. Only... this adds quite a few context switches every time
accessing files. Sigh.
I just pushed 2d81f6ebe3dc ("Cygwin: open: always fix up cached DOS file
attributes after NtCreateFile").
Try the upcoming cygwin-3.7.0-0.47.g9e6193576f34.
With a local build of 3.7.0-dev-49-g42df80dad079.x86_64, both the
testcase and stress-ng no longer fail.
--
Regards,
Christian
--
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: No errno set after too many open("/dev/ptmx", ...)
On Mar 30 15:01, Christian Franke wrote: Found because 'stress-ng --pty 1' reports "open /dev/ptmx failed, errno=0": $ uname -r # also with 3.5.7-1 and 3.6.0-1.x86_64 3.7.0-0.19.g6c5537c0298e.x86_64 ... $ gcc -o manyptmx manyptmx.c $ ./manyptmx 3, 2000 4, 2000 ... 127, 2000 128, 2000 0 [main] manyptmx 204 tty_list::allocate: No pty allocated -1, 2000 Problem no longer occurs with 3.7.0-0.33.g6e75829e117f. open() now fails with EMFILE. BTW, 'stress-ng --pty 1' then fails because tcdrain(), tcflow() and TIOCINQ are not implemented for ptys. Not a problem, I guess. -- Regards, Christian -- 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
No errno set after too many open("/dev/ptmx", ...)
Found because 'stress-ng --pty 1' reports "open /dev/ptmx failed, errno=0":
$ uname -r # also with 3.5.7-1 and 3.6.0-1.x86_64
3.7.0-0.19.g6c5537c0298e.x86_64
$ cat manyptmx.c
#include
#include
#include
#include
int main()
{
int fd;
errno = __ELASTERROR;
do {
fd = open("/dev/ptmx", O_RDWR);
printf("%d, %d\n", fd, errno);
} while (fd >= 0);
return 0;
}
$ gcc -o manyptmx manyptmx.c
$ ./manyptmx
3, 2000
4, 2000
...
127, 2000
128, 2000
0 [main] manyptmx 204 tty_list::allocate: No pty allocated
-1, 2000
--
Regards,
Christian
--
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: cygwin-devel vs libbsd-devel: arc4random_stir() macro in stdlib.h breaks bsd/stdlib.h
Corinna Vinschen via Cygwin wrote: On Mar 14 17:12, Corinna Vinschen via Cygwin wrote: On Mar 14 16:50, Corinna Vinschen via Cygwin wrote: On Mar 14 13:48, Christian Franke via Cygwin wrote: $ nm /usr/lib/libbsd.dll.a | grep ' arc4random' || echo not found not found I guess: - arc4random_addrandom() should be removed from libcygwin.a or added to cygwin/stdlib.h. No, we can't do that (OpenSSH) Ooooh, you mean arc4random_addrandom. My excuse for a brain was still thinking of arc4random_stir *facepalm* Hmm... - all arc4random*() should be hidden for __CYGWIN__ in bsd/stdlib.h. This, we can do. Let me check. Check out cygwin-3.6.0-0.440.g5ec497dc80bc in conjunction with libbsd-0.12.2-4, both building right now. Looks good ... $ nm /usr/lib/libcygwin.a | grep ' arc4random' T arc4random T arc4random_buf T arc4random_uniform $ gcc -E -xc - <<<'#include ' | grep arc4random __uint32_t arc4random (void); __uint32_t arc4random_uniform (__uint32_t); void arc4random_buf (void *, size_t); $ nm /usr/lib/libbsd.dll.a | grep ' arc4random' || echo not found not found ... except that bsd/stdlib.h still advertises the functions which could no longer be linked: $ gcc -E -xc - <<<'#include ' | grep arc4random __uint32_t arc4random (void); __uint32_t arc4random_uniform (__uint32_t); void arc4random_buf (void *, size_t); void arc4random_stir(void); void arc4random_addrandom(unsigned char *dat, int datlen); Mostly cosmetic as this would not result in false positive AC_CHECK_FUNC*() results. I would suggest to revert the recent bsd/stdlib.h change and move the __CYGWIN__ check to the top level #if instead, see attached patch. -- Thanks, Christian --- bsd/stdlib.h-0.12.2-4 2025-03-14 20:18:36.0 +0100 +++ bsd/stdlib.h2025-03-15 12:35:53.465262000 +0100 @@ -51,12 +51,10 @@ #include __BEGIN_DECLS -#if !defined(__APPLE__) && !defined(__sun) -#if (!defined(__GLIBC__) || \ +#if !defined(__APPLE__) && !defined(__CYGWIN__) && !defined(__sun) +#if !defined(__GLIBC__) || \ !__GLIBC_PREREQ(2, 36) || \ - !defined(_DEFAULT_SOURCE)) && \ - (!defined(__CYGWIN__) || \ - !__BSD_VISIBLE) +!defined(_DEFAULT_SOURCE) uint32_t arc4random(void); void arc4random_buf(void *_buf, size_t n); uint32_t arc4random_uniform(uint32_t upper_bound); -- 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: cygwin-devel vs libbsd-devel: arc4random_stir() macro in stdlib.h breaks bsd/stdlib.h
Corinna Vinschen via Cygwin wrote: On Mar 13 08:59, Christian Franke via Cygwin wrote: Problem introduced in a8891c93: $ cygcheck -f /usr/include/stdlib.h cygwin-devel-3.6.0-0.430.ga942476236b5 $ cygcheck -f /usr/include/bsd/stdlib.h libbsd-devel-0.12.2-2 $ gcc -c -xc - <<<'#include ' In file included from :1: /usr/include/bsd/stdlib.h:62:26: error: macro "arc4random_stir" passed 1 arguments, but takes just 0 62 | void arc4random_stir(void); | ^ In file included from /usr/include/stdlib.h:26, from /usr/include/bsd/stdlib.h:32: /usr/include/cygwin/stdlib.h:26: note: macro "arc4random_stir" defined here 26 | #define arc4random_stir() Should work again with cygwin-3.6.0-0.431.gad29c33229e5 This fixes the problem, thanks. There are possibly still inconsistencies: $ gcc -E -xc - <<<'#include ' | grep arc4random_stir void arc4random_stir(void); $ gcc -E -xc - <<<'#include ' | grep arc4random_stir void arc4random_stir(void); // from cygwin/stdlib.h void arc4random_stir(void); // from bsd/stdlib.h $ gcc -E -xc - <<<'#include ' | grep arc4random_addrandom $ gcc -E -xc - <<<'#include ' | grep arc4random_addrandom void arc4random_addrandom(unsigned char *dat, int datlen); $ gcc -E -xc - <<<'#include ' | grep arc4random_buf void arc4random_buf (void *, size_t); // from stdlib.h void arc4random_buf(void *_buf, size_t n); // from bsd/stdlib.h $ nm /usr/lib/libcygwin.a | grep ' arc4random' T arc4random T arc4random_addrandom T arc4random_buf T arc4random_stir T arc4random_uniform $ nm /usr/lib/libbsd.dll.a | grep ' arc4random' || echo not found not found I guess: - arc4random_addrandom() should be removed from libcygwin.a or added to cygwin/stdlib.h. - all arc4random*() should be hidden for __CYGWIN__ in bsd/stdlib.h. -- Regards, Christian -- 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: unix socket hang when connect
Yuyi Wang via Cygwin wrote: Thank you Christian, setting SO_PEERCRED on the client socket works. It's a little wierd, though. Is it OK to always set it to NULL on a unix socket? No, this is a Cygwin extension, originally added for postfix. -- Regards, Christian -- 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: unix socket hang when connect
Yuyi Wang via Cygwin wrote:
Below is a simple unix socket testing code. It creates a unix socket server and
a client to connect to it immediately. It works on Linux and macOS, but hangs on
cygwin. bind + listen work well, but seems that the connect method never
returns.
#include
#include
#include
#include
#include
#include
#include
#define SOCKET_PATH "/tmp/example_socket"
int main() {
int server_fd, client_fd;
struct sockaddr_un server_addr;
socklen_t client_len;
server_fd = socket(AF_UNIX, SOCK_STREAM, 0);
if (server_fd == -1) {
perror("server socket");
exit(EXIT_FAILURE);
}
memset(&server_addr, 0, sizeof(server_addr));
server_addr.sun_family = AF_UNIX;
strncpy(server_addr.sun_path, SOCKET_PATH, sizeof(server_addr.sun_path) -
1);
if (bind(server_fd, (struct sockaddr*)&server_addr, sizeof(server_addr))
== -1) {
perror("bind");
exit(EXIT_FAILURE);
}
if (listen(server_fd, 1) == -1) {
perror("listen");
exit(EXIT_FAILURE);
}
printf("Server is listening on %s\n", SOCKET_PATH);
client_fd = socket(AF_UNIX, SOCK_STREAM, 0);
if (client_fd == -1) {
perror("client socket");
exit(EXIT_FAILURE);
}
if (connect(client_fd, (struct sockaddr*)&server_addr,
sizeof(server_addr)) == -1) {
perror("connect");
exit(EXIT_FAILURE);
}
printf("Client connected to server\n");
close(client_fd);
close(server_fd);
unlink(SOCKET_PATH);
return 0;
}
May be this issue which also affected postfix:
https://sourceware.org/legacy-ml/cygwin/2014-08/msg00420.html
Try:
setsockopt(sd, SOL_SOCKET, SO_PEERCRED, NULL, 0);
available since:
https://cygwin.com/git/?p=newlib-cygwin.git;a=commit;h=697b9afe0
and may still work (I don't know).
--
Regards,
Christian
--
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: Tuning ls, ls -l, find ., find . -ls performance for very large dirs (60000+ files/dir)
Brian Inglis via Cygwin wrote: On 08/04/2025 19:05, Mark Liam Brown via Cygwin wrote: Are there tuning variables to improve ls, ls -l, find ., find . -ls performance for very large dirs? If we have a SMB dir with 6+ entries a simple ls -l can take MANY minutes (22+mins), while cmd.exe dir just floods the terminal with results immediately. I just remembered noticing my /var/log/ entries jumped looking at my last Cygwin upgrade log, so before I clean it up into subdirs, let's try some stuff! If you just want a directory name dump, use \ls -U|--sort=none or \ls -f which is like -aU; command prefix \ overrides the usual aliases like -CF --color=auto: $ time \ls -1U /var/log/ | \wc -lwmcL 54049 54049 1885787 1885787 38 real 0m0.336s user 0m0.046s sys 0m0.295s $ time \ls -1f /var/log/ | \wc -lwmcL 54051 54051 1885792 1885792 38 real 0m0.347s user 0m0.140s sys 0m0.232s even with -l, it's only a few seconds: $ time \ls -lU /var/log/ | \wc -lwmcL 54050 486455 4966716 4966716 102 real 0m15.891s user 0m1.421s sys 0m14.560s $ time \ls -lf /var/log/ | \wc -lwmcL 54052 486473 4966835 4966835 102 real 0m15.858s user 0m1.405s sys 0m14.374s One reason for the above difference is possibly that Cygwin supports the 'dirent.d_type' field for quite some time and tools like 'ls' and 'find' use it to avoid stat() calls. Fast - stat() calls avoided: ls -R find find -type f -name 'some*file' Fast if only few entries require stat(): find -type f -name 'some*file' -mtime +42 # only -mtime requires stat() find -mtime +42 -type f -name 'some*file' # find does 'cheap' checks first Slow - requires stat() for each entry: ls -Rt ls -RS ls -Rl find -mtime +42 find -ls -- Regards, Christian -- 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
ftruncate() may fail with EISDIR if other process calls open()
Found because 'stress-ng --fcntl 2 --verify' reports "ftruncate failed,
errno=21":
Testcase:
$ uname -r # also with 3.6.0-1 and 3.5.7-1
3.7.0-0.43.g779e46b5b3ee.x86_64
$ cat ftruncopen.c
#include
#include
#include
#include
int main()
{
const char name[] = "file.tmp";
unlink(name);
pid_t pid = fork();
if (pid == (pid_t)-1) {
perror("fork"); return 1;
}
int status = 1;
int fd = open(name, O_WRONLY|O_CREAT|O_TRUNC, 0600);
if (fd < 0) {
fprintf(stderr, "%d: ", (int)getpid()); perror("open");
}
else if (!pid && ftruncate(fd, 0) < 0) {
fprintf(stderr, "%d: ", (int)getpid()); perror("ftruncate");
}
else
status = 0;
printf("%d: exit(%d)\n", (int)getpid(), status);
if (!pid)
return status;
int status2 = 0;
wait(&status2);
return (status || status2);
}
$ gcc -o ftruncopen ftruncopen.c
$ while ./ftruncopen; do echo retry; done
11223: exit(0)
11222: exit(0)
retry
11225: exit(0)
11224: exit(0)
retry
11227: ftruncate: Is a directory
11226: exit(0)
11227: exit(1)
Problem did not occur if
- O_TRUNC is removed, or
- unlink() is removed and the file exists, or
- it is run with 'taskset 0x1'.
--
Regards,
Christian
--
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: Cannot install git-svn
Wiktor S. via Cygwin wrote: Hi,recently it become impossible to install git-svn because of Perl dependency:Problem 1/1nothing provides perl5_036 needed by subversion-perl-1.14.2-1Solution 1/1 (default) - do not ask to install git-svn-2.45.1-1-- Wiktor Sywula setup.ini: ... @ git-svn ... depends2: ... subversion-perl ... @ subversion-perl ... depends2: ... perl5_036, ... ... $ grep -E '^(@|provides:) perl5_' setup.ini provides: perl5_040 provides: perl5_040 provides: perl5_040 $ grep -c '^depends2:.* perl5_036' setup.ini 429 Perl5_036 packages removed from the mirrors too early ? -- Regards, Christian -- 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: cygstart: buffer overflow when a URI is passed (cygutils-1.4.17-[23])
Mark Geisert via Cygwin wrote:
Drat, typo alert:
It looks to me like that 'if' statement should read
if (mbstowcs (*wcs_path, *mbs_path, len) ...
if (mbstowcs (*wcspath, mbs_path, len) ...
Use 'len + 1', otherwise the result would possibly be not null terminated.
POSIX says: "The array shall not be zero-terminated if the value
returned is /n/.".
Linux mbstowcs(3) says: "... the programmer should make sure dsize is
greater than or equal to mbstowcs(NULL,src,0)+1."
Example:
#include
#include
int main()
{
const char src[] = "123";
wchar_t dst[4] = L"...!";
size_t len = mbstowcs(NULL, src, 0);
printf("len=%zu\n", len);
mbstowcs(dst, src, len);
printf("len: '%.4S'\n", dst);
mbstowcs(dst, src, len+1);
printf("len+1: '%.4S'\n", dst);
printf("len+2:\n");
mbstowcs(dst, src, len+2);
return 0;
}
Result if compiled with -O -D_FORTIFY_SOURCE:
len=3
len: '123!'
len+1: '123'
len+2:
*** buffer overflow detected ***: terminated
Aborted
--
Regards,
Christian
--
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: cygstart: buffer overflow when a URI is passed (cygutils-1.4.17-[23])
ggl329 via Cygwin wrote:
Hi all,
I've encountered a possible bug in cygstart.
It seems to abort when a URI is passed to it.
$ cygcheck -dc | grep cygutils
cygutils 1.4.17-3
$ cygstart https://www.google.com
*** buffer overflow detected ***: terminated
Aborted
Possibly no regression but longstanding bug which is now detected thanks
to gcc12's __builtin_dynamic_object_size() feature and -D_FORTIFY_SOURCE=3:
cygstart.c:
cygstart_mbs_to_wcs (const char *mbs_path, wchar_t **wcs_path)
{
...
*wcs_path = (wchar_t *) malloc ((len + 1) * sizeof (wchar_t));
...
// *** buffer overflow detected *** because the length parameter
// should specify the number of characters instead of bytes:
if (mbstowcs (*wcs_path, mbs_path, (len + 1) * sizeof (wchar_t)) ...
...
}
--
Regards,
Christian
--
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: Signing cygwin.com binaries with signtool by default ?
Brian Inglis via Cygwin wrote: Or get a free Let's Encrypt cert as many orgs do. Unfortunately Let's Encrypt does not support code signing: https://letsencrypt.org/docs/faq/#does-let-s-encrypt-issue-certificates-for-anything-other-than-ssl-tls-for-websites -- Regards, Christian -- 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
cygwin 3.6.0 vs. libbsd 0.11.7-3: -lbsd breaks setproctitle()
Testcase:
$ uname -r
3.6.0-0.375.ged18acfe8c76.x86_64
$ cygcheck -f /usr/include/bsd/unistd.h
libbsd-devel-0.11.7-3
$ cat spt.c
#include
int main(int argc, char **argv, char **envp)
{
initsetproctitle(argc, argv, envp);
setproctitle("argc = %d", argc);
sleep(2);
return 0;
}
$ gcc -o spt-bsdovl -isystem /usr/include/bsd -DLIBBSD_OVERLAY spt.c -l bsd
$ gcc -o spt-bsd spt.c -l bsd
$ gcc -o spt-nobsd spt.c
$ ./spt-bsdovl
spt-bsdovl: setproctitle not initialized, please either call
setproctitle_init() or link against libbsd-ctor.
$ ./spt-bsd
spt-bsd: setproctitle not initialized, please either call
setproctitle_init() or link against libbsd-ctor.
$ ./spt-nobsd & procps -o pid,args -p $!
[1] 2750
PID COMMAND
2750 spt-nobsd: argc = 1
$ objdump -p spt-bsd.exe | grep setproctitle_init || echo NOT FOUND
NOT FOUND
$ objdump -p spt-bsd.exe | grep -B2 setproctitle
DLL Name: cygbsd-0.dll
vma: Ordinal Hint Member-Name Bound-To
80e0 0034 setproctitle
$ objdump -p spt-nobsd.exe | grep -B14 setproctitle
DLL Name: cygwin1.dll
vma: Ordinal Hint Member-Name Bound-To
...
8128 0544 setproctitle
cygbsd-0.dll:setproctitle_init exists but is no longer linked because
the static inline takes precedence:
/usr/include/bsd/unistd.h:
void setproctitle_init(int argc, char *argv[], char *envp[]);
/usr/include/sys/unistd.h:
static inline void setproctitle_init (int, char *[], char *[]) {}
Conflict is likely introduced by (not present in 3.5.*):
https://cygwin.com/git/?p=newlib-cygwin.git;a=commit;h=2e7f7b96
--
Regards,
Christian
--
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: cygwin 3.6.0 vs. libbsd 0.11.7-3: -lbsd breaks setproctitle()
Hi Corinna,
Corinna Vinschen via Cygwin wrote:
Hi Christian,
On Feb 19 11:14, Christian Franke via Cygwin wrote:
Testcase:
$ uname -r
3.6.0-0.375.ged18acfe8c76.x86_64
$ cygcheck -f /usr/include/bsd/unistd.h
libbsd-devel-0.11.7-3
$ cat spt.c
#include
int main(int argc, char **argv, char **envp)
{
initsetproctitle(argc, argv, envp);
setproctitle("argc = %d", argc);
sleep(2);
return 0;
}
$ gcc -o spt-bsdovl -isystem /usr/include/bsd -DLIBBSD_OVERLAY spt.c -l bsd
$ gcc -o spt-bsd spt.c -l bsd
$ gcc -o spt-nobsd spt.c
$ ./spt-bsdovl
spt-bsdovl: setproctitle not initialized, please either call
setproctitle_init() or link against libbsd-ctor.
$ ./spt-bsd
spt-bsd: setproctitle not initialized, please either call
setproctitle_init() or link against libbsd-ctor.
$ ./spt-nobsd & procps -o pid,args -p $!
[1] 2750
PID COMMAND
2750 spt-nobsd: argc = 1
The problem the Cygwin patch was supposed to fix is that the libbsd
version of setproctitle just doesn't work correctly on Cygwin:
$ uname -r
3.5.7-1.x86_64
$ ./spt-bsdovl & procps -o pid,args -p $!
[1] 140
PID COMMAND
140 spt-bsdovl:
The way the include file /usr/include/bsd/unistd.h is designed,
we could make sure the libbsd version is used, by tweaking
/usr/include/sys/unistd.h:
diff --git a/newlib/libc/include/sys/unistd.h b/newlib/libc/include/sys/unistd.h
index e62e38d10ccf..732356d6a14e 100644
--- a/newlib/libc/include/sys/unistd.h
+++ b/newlib/libc/include/sys/unistd.h
@@ -212,7 +212,7 @@ int setpgid (pid_t __pid, pid_t __pgid);
#if __SVID_VISIBLE || __XSI_VISIBLE >= 500
int setpgrp (void);
#endif
-#if defined(__CYGWIN__) && __BSD_VISIBLE
+#if defined(__CYGWIN__) && __BSD_VISIBLE && !defined(LIBBSD_OVERLAY)
/* Stub for Linux libbsd compatibility. */
#define initsetproctitle(c, a, e) setproctitle_init((c), (a), (e))
static inline void setproctitle_init (int, char *[], char *[]) {}
But that still allows to link against a non-working setproctitle.
Yes, and it won't work if bsd/unistd.h is included without
LIBBSD_OVERLAY which is discouraged but still documented on libbsd(7).
So I think we rather shouldn't supply the libbsd version of
setproctitle_init/setproctitle anymore, as soon as cygwin 3.6.0 is
released.
What do you think?
Makes sense. But then existing programs already using the functions from
cygbsd-0.dll would no longer start. Perhaps keep the symbols in the DLL
only for some time?
--
Regards,
Christian
--
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: lost signal
Roland Mainz via Cygwin wrote: On Fri, Mar 7, 2025 at 9:01 AM Takashi Yano via Cygwin wrote: On Fri, 7 Mar 2025 16:29:51 +0900 Takashi Yano wrote: On Wed, 5 Mar 2025 11:23:26 +0100 Christian Franke wrote: ... Unfortunately signals may be lost, a new testcase is attached: ... $ ./lostsig 1163: fork()=1164 SIGALRM x 10 SIGSTOP SIGTERM SIGCONT waitpid()... [ALRM] [TERM] ...hangs... A 'ps' is a second terminal then shows that the child process is still in S)topped state. 'kill -CONT ...' works to continue. If the testcase is assigned to a single core with 'taskset 0x1 ...', it apparently always hangs. Thanks for the report and the testcase. The current implementation of the signal queue has the following problems: 1) Signals in the queue are processed in a disordered manner. 2) If the same signal is already in the queue, new signal is discarded. I am working on this issue and almost finished. Now I'm testing. Please wait a while. Thanks for working on this complex topic! BTW, the resut of your testcase in Linux is as follows: 231873: fork()=231874 SIGALRM x 10 [ALRM] [ALRM] [ALRM] SIGSTOP SIGTERM SIGCONT waitpid()... [TERM] 231874: 3 SIGALRM received, exit(42) waidpid()=231874, status=0x2a00 Signal-lost also happens. However, it does not hang in Linux. Sorry, I didn't clarify that the lost SIGALRMs are not the problem. These are issued solely to trigger the lost SIGCONT problem. A test on Linux also shows that signal handlers may be called out of order: 1070: fork()=1071 SIGALRM x 10 SIGSTOP SIGTERM SIGCONT waitpid()... [TERM] [ALRM] [ALRM] 1071: 2 SIGALRM received, exit(42) waidpid()=1071, status=0x2a00 Same if sigqueue() is used instead of kill(). BTW: If you do testing PLEASE use |sigqueue()| for |SIGRT*| signals (and check the return code!) and NOOT |kill()|, because |kill()| cannot communicate if there was no room left to queue another signal. Thanks for clarification. If the testcase is modified to use sigqueue() instead of kill() and SIGRTMIN+0/1 instead of SIGALRM/TERM, sigqueue() also always succeeds. On Linux, no signal is lost then, but the disorder may still occur. -- Regards, Christian -- 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: sched_getaffinity() always returns the full cpu mask
Brian Inglis via Cygwin wrote: On 2025-03-08 10:11, Christian Franke via Cygwin wrote: $ grep processor /proc/cpuinfo | tail -1 # i7-14700K processor : 27 coreutils nproc should show the equivalent result 28 Works as expected: $ nproc 28 $ busybox nproc 28 -- 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
sched_getaffinity() always returns the full cpu mask
Testcase: $ grep processor /proc/cpuinfo | tail -1 # i7-14700K processor : 27 $ sleep 60 & taskset 0x1 sleep 60 & [1] 62094 [2] 62095 $ taskset -p 62094 pid 62094's current affinity mask: fff $ taskset -p 62095 pid 62095's current affinity mask: fff Another test shows that the affinity mask is correctly set to 0x1 by sched_setaffinity(). In sched.cc:__sched_getaffinity_sys(), GetProcessAffinityMask() is called, but its 'procmask' result is never used. The returned cpu_set is build using groupmask(__get_cpus_per_group ()) which is constant, here 0xfff. The original commit 641ecb07 likely worked (until 687c4bad^) on older Windows versions which did not support cpu groups. I don't know how to fix this for systems with more than one cpu group, so no patch provided. It might be needed to handle interesting corner cases: "If the process had explicitly set the affinity of one or more of its threads outside of the process' primary group, the function returns zero for both affinity masks." https://learn.microsoft.com/en-us/windows/win32/api/winbase/nf-winbase-getprocessaffinitymask -- Regards, Christian -- 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: cygwin 3.6.0: No signals received after swapcontext() is used
Corinna Vinschen via Cygwin wrote: On Mar 6 13:24, Christian Franke via Cygwin wrote: Found because 'stress-ng --context 1 ...' always hangs. The attached testcase uses the example from Linux swapcontext(3) to call the context functions. Just tested with 3.5.3 and it doesn't work there, either. So yeah, it's a bug, but it's not a 3.6 regression and of minor importance. We can look into that for 3.7. This is possibly a regression introduced in 3.0.6. A comparison of strace outputs of signal handling before and after the swapcontext() calls reveals that 'incyg' is incorrectly set after swapcontext(). A revert of https://cygwin.com/git/?p=newlib-cygwin.git;a=commit;h=c5f9eed1 fixes both the testcase and 'stress-ng --context ...'. No patch provided because I'm not sure how to handle the (at least) two other use cases of setcontext() correctly: - the call from _cygtls::call_signal_handler(), and - a call from a signal handler. -- Regards, Christian -- 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
cygwin 3.6.0: No signals received after swapcontext() is used
Found because 'stress-ng --context 1 ...' always hangs.
The attached testcase uses the example from Linux swapcontext(3) to call
the context functions.
$ uname -r
3.6.0-0.419.g3c1308ed890e.x86_64
$ gcc -o ctxnosig ctxnosig.c
$ ./ctxnosig # ... and hit ^C
waste_time: started
[^C][SIGINT]
waste_time: returning, sigflag=1
main2: swapcontext(&uctx_main, &uctx_func2)
func2: started
func2: swapcontext(&uctx_func2, &uctx_func1)
func1: started
func1: swapcontext(&uctx_func1, &uctx_func2)
func2: returning
func1: returning
main2: exiting
waste_time: started
[^C][^C][^C][^C][^C][^C][^C][^C][^C][^C]...
waste_time: returning, sigflag=0
main: sleep(5)...
[SIGINT]
[SIGINT]
[^C][SIGINT]
main: sleep(5)=2
main: exiting, 4 SIGINT received
Possibly a minor issue because these functions are obsoleted (last seen
in POSIX 2004), but at least cygruby*.dll import these:
$ objdump -p /bin/cygruby320.dll | grep context
00378ca8 0286 getcontext
00378e08 0391 makecontext
003791c0 05cd swapcontext
...
--
Regards,
Christian
// BEGIN: example from Linux swapcontext(3)
#include
#include
#include
static ucontext_t uctx_main, uctx_func1, uctx_func2;
#define handle_error(msg) \
do { perror(msg); exit(EXIT_FAILURE); } while (0)
static void
func1(void)
{
printf("func1: started\n");
printf("func1: swapcontext(&uctx_func1, &uctx_func2)\n");
if (swapcontext(&uctx_func1, &uctx_func2) == -1)
handle_error("swapcontext");
printf("func1: returning\n");
}
static void
func2(void)
{
printf("func2: started\n");
printf("func2: swapcontext(&uctx_func2, &uctx_func1)\n");
if (swapcontext(&uctx_func2, &uctx_func1) == -1)
handle_error("swapcontext");
printf("func2: returning\n");
}
static void
main2(int argc, char *argv[])
{
char func1_stack[16384];
char func2_stack[16384];
if (getcontext(&uctx_func1) == -1)
handle_error("getcontext");
uctx_func1.uc_stack.ss_sp = func1_stack;
uctx_func1.uc_stack.ss_size = sizeof(func1_stack);
uctx_func1.uc_link = &uctx_main;
makecontext(&uctx_func1, func1, 0);
if (getcontext(&uctx_func2) == -1)
handle_error("getcontext");
uctx_func2.uc_stack.ss_sp = func2_stack;
uctx_func2.uc_stack.ss_size = sizeof(func2_stack);
/* Successor context is f1(), unless argc > 1 */
uctx_func2.uc_link = (argc > 1) ? NULL : &uctx_func1;
makecontext(&uctx_func2, func2, 0);
printf("main2: swapcontext(&uctx_main, &uctx_func2)\n");
if (swapcontext(&uctx_main, &uctx_func2) == -1)
handle_error("swapcontext");
printf("main2: exiting\n");
}
// END: example from Linux swapcontext(3)
//
#include
#include
#include
static volatile sig_atomic_t sigcnt, sigflag;
static void sighandler(int sig)
{
(void)sig;
++sigcnt;
sigflag = 1;
write(1, "[SIGINT]\n", 9);
}
static void waste_time()
{
printf("waste_time: started\n");
int flag = 0;
sigflag = 0;
volatile double x = 1.0;
const int n = 100*1000*1000; // ~5s on i7-14700
for (int i = 0; i < n && !flag; i++) {
x = asin(sin(x));
flag = sigflag;
}
printf("waste_time: returning, sigflag=%d\n", flag);
}
int main(int argc, char *argv[])
{
signal(SIGINT, sighandler);
waste_time(); // signals received
main2(argc, argv); // swapcontext example
waste_time(); // no signals received
printf("main: sleep(5)...\n");
printf("main: sleep(5)=%u\n", sleep(5)); // aborted by (new) signal (only)
printf("main: exiting, %d SIGINT received\n", sigcnt);
return 0;
}
--
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: sched_getaffinity() always returns the full cpu mask
Mark Geisert via Cygwin wrote: Hi Christian, On 3/8/2025 9:11 AM, Christian Franke via Cygwin wrote: Testcase: $ grep processor /proc/cpuinfo | tail -1 # i7-14700K processor : 27 $ sleep 60 & taskset 0x1 sleep 60 & [1] 62094 [2] 62095 $ taskset -p 62094 pid 62094's current affinity mask: fff $ taskset -p 62095 pid 62095's current affinity mask: fff This may well be the first test of Cygwin's affinity support on a system where the cpu mask bit length isn't a power of 2. I did test such but seeing it on hardware is another matter. Are there in fact just 28 hardware processors on this system? ... One physical cpu with 20 cores and 28 threads (i7-14700K: 8P/HT + 12E) GetProcessAffinityMask(., ., &sysmask) returns sysmask=0xfff GetProcessGroupAffinity(., &groupcount, grouparray) returns groupcount=1, grouparray[0] = 0 ... Does Windows (or Linux for that matter) allow one to set cpu group size? I would think the BIOS would want control over that, with the OSs just providing read access to what was chosen. For 28 processors, a single group of 28 processors, or either 4 groups of 7 procs, or 7x4, or even 2x14 or 14x2 are plausible if not all useful. I guess cpu groups are intended to reflect the physical cpus. I don't know whether this assignment could be changed. -- Regards, Christian -- 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: cygwin 3.6.0: No signals received after swapcontext() is used
Corinna Vinschen via Cygwin wrote:
On Mar 8 12:07, Christian Franke via Cygwin wrote:
...
This is possibly a regression introduced in 3.0.6. A comparison of strace
outputs of signal handling before and after the swapcontext() calls reveals
that 'incyg' is incorrectly set after swapcontext(). A revert of
https://cygwin.com/git/?p=newlib-cygwin.git;a=commit;h=c5f9eed1
fixes both the testcase and 'stress-ng --context ...'.
Ahhh, good point. When I looked into get/setcontext last week, I was
wondering about this _my_tls.incyg = true, but didn't look into the
history.
I'm not sure if this was the right thing to do anyway. Unfortunately,
my commit message of the time was really really bad, and I don't see
anything in the mailing lists pointing out where the idea to set iscyg
was coming from.
In the light of the signal changes in Cygwin, it might be a good idea to
drop it.
No patch provided because I'm not sure how to handle the (at least) two
other use cases of setcontext() correctly:
- the call from _cygtls::call_signal_handler(), and
I re-read the POSIX and Linux man pages on sigaction. None of them
claim that the context given to the signal handler is anything other
than read-only information given to the handler, and, worse, supposed
to be used by the signal mechanism after the signal handler returns.
So it seems calling setcontext() on the vague notion that the signal
handler expects this if it changed the context, was a bug from the start.
I'm inclined to apply this patch:
diff --git a/winsup/cygwin/exceptions.cc b/winsup/cygwin/exceptions.cc
index 6d8985374b9e..a05883e3fc4f 100644
--- a/winsup/cygwin/exceptions.cc
+++ b/winsup/cygwin/exceptions.cc
@@ -1850,14 +1850,6 @@ _cygtls::call_signal_handler ()
? context.uc_sigmask : this_oldmask);
if (this_errno >= 0)
set_errno (this_errno);
- if (this_sa_flags & SA_SIGINFO)
- {
- /* If more than just the sigmask in the context has been changed by
-the signal handler, call setcontext. */
- context_copy.uc_sigmask = context.uc_sigmask;
- if (memcmp (&context, &context_copy, sizeof context) != 0)
- setcontext (&context);
- }
}
/* FIXME: Since 2011 this return statement always returned 1 (meaning
@@ -1899,7 +1891,6 @@ setcontext (const ucontext_t *ucp)
{
PCONTEXT ctx = (PCONTEXT) &ucp->uc_mcontext;
set_signal_mask (_my_tls.sigmask, ucp->uc_sigmask);
- _my_tls.incyg = true;
RtlRestoreContext (ctx, NULL);
/* If we got here, something was wrong. */
set_errno (EINVAL);
It's not quite clear to me why signal handling should be broken if
setcontext is used inside a signal handler. The incyg flag is false
when running the signal handler and that's correct. Theoretically a
running signal handler is not different from other process code.
Do you have an STC, by any chance?
The attached testcase should test the following use cases of setcontext:
- call from regular user space
- call from a signal handler interrupting user space
- call from a signal handler interrupting a system call
It works as expected ... until the signal count reaches 256. Then
signals are again only delivered from inside of a system call.
$ uname -r
3.6.0-0.427.g1d97f8aa4385.x86_64
$ gcc -o ctxloop ctxloop.c
$ ./ctxloop # and then press+hold ^C
0x0: sigcnt=0
0x7cc40: main
0x7cbb0: waste_time
[SIGINT]
0x7c4c0: sigcnt=1
0x7cc40: main
0x7cbb0: waste_time
[SIGINT]
0x7c440: sigcnt=2
0x7cc40: main
0x7cbb0: waste_time
[SIGINT]
0x7c440: sigcnt=3
0x7cc40: main
0x7cbb0: waste_time
[SIGINT]
0x7c400: sigcnt=4
0x7cc40: main
0x7cbb0: waste_time
...
[SIGINT]
0x7c400: sigcnt=255
0x7cc40: main
0x7cbb0: waste_time
[SIGINT]
0x7c400: sigcnt=256
0x7cc40: main
0x7cbb0: waste_time
[^C][^C][^C]
to continue, 'q' to quit
[SIGINT]
0x7c630: sigcnt=257
0x7cc40: main
0x7cbb0: waste_time
[^C][^C][^C]
to continue, 'q' to quit
[SIGINT]
...
Interesting... Hmm... is there some 8-bit counter which overflows and
then stucks at 0xff or 0x00?
--
Regards,
Christian
#include
#include
#include
#include
#include
static ucontext_t uctx;
static volatile sig_atomic_t sigcnt;
static volatile void* sigframe;
static void sighandler(int sig)
{
(void)sig;
++sigcnt;
sigframe = __builtin_frame_address(0);
write(1, "[SIGINT]\n", 9);
if (setcontext(&uctx)) // goto loop;
write(1, "[FAIL]\n", 7);
}
static void __attribute__ ((noinline)) waste_time()
{
printf("%p: waste_time\n", __builtin_frame_address(0));
volatile double x = 1.0;
const int n = 45*1000*1000; // ~2.5s on i7-14700
for (int i = 0; i < n; i++)
x = asin(sin(x));
}
int main()
{
signal(SIGINT, sighandler);
if (getcontext(&uctx)) {
Re: cygwin 3.6.0: Signals may fail permanently if received after SIGSTOP
Takashi Yano via Cygwin wrote:
On Mon, 24 Feb 2025 11:29:59 +0100
Christian Franke wrote:
Found with 'stress-ng --cpu-sched 1':
Testcase (attached):
$ uname -r
3.6.0-0.387.g8cebbb2b42bf.x86_64
$ gcc -o timersig timersig.c
$ ./timersig
638: fork()=639
!...!SIGSTOP: Permission denied
0 [itimer] timersig 639 sig_send: error sending signal 14, pid 639,
pipe handle 0x14C, nb 0, packsize 192, Win32 error 0
SIGKILL: Permission denied
$ kill 639
-bash: kill: (639) - Permission denied
$ kill -9 639
-bash: kill: (639) - Permission denied
$ /bin/kill --force 639
$ /bin/kill --force 639
kill: 639: No such process
A similar problem, but without the "error sending signal" message,
occurs if the timer is not used but the parent process issues SIGSTOP
SIGALRM SIGCONT ... sequences.
Thanks for the report, especially for the test case. I was able to
easily reproduce the issue. However, I haven't found the cause until
today. I spent 3 days investigating and discovered three bugs that
prevent the test case from behaving as expected.
I'll submit the patch seriese shotly.
Testcase works as expected with 3.6.0-0.419.g3c1308ed890e.x86_64, thanks!
Unfortunately signals may be lost, a new testcase is attached:
$ uname -r
3.6.0-0.419.g3c1308ed890e.x86_64
$ gcc -o lostsig lostsig.c
$ ./lostsig
1157: fork()=1158
SIGALRM x 10
[ALRM]
[ALRM]
[ALRM]
SIGSTOP
[ALRM]
SIGTERM
SIGCONT
waitpid()...
[TERM]
1158: 4 SIGALRM received, exit(42)
waidpid()=1158, status=0x2a00
$ ./lostsig
1163: fork()=1164
SIGALRM x 10
SIGSTOP
SIGTERM
SIGCONT
waitpid()...
[ALRM]
[TERM]
...hangs...
A 'ps' is a second terminal then shows that the child process is still
in S)topped state. 'kill -CONT ...' works to continue.
If the testcase is assigned to a single core with 'taskset 0x1 ...', it
apparently always hangs.
--
Regards,
Christian
#include
#include
#include
#include
#include
#include
static volatile sig_atomic_t sigcnt, term;
static void sighandler1(int sig)
{
(void)sig;
++sigcnt;
write(1, "[ALRM]\n", 7);
}
static void sighandler2(int sig)
{
(void)sig;
term = 1;
write(1, "[TERM]\n", 7);
}
int main()
{
pid_t pid = fork();
if (pid == (pid_t)-1) {
perror("fork"); return 1;
}
if (!pid) {
signal(SIGALRM, sighandler1);
signal(SIGTERM, sighandler2);
while (!term)
sched_yield();
printf("%d: %d SIGALRM received, exit(42)\n", (int)getpid(), sigcnt);
fflush(stdout);
_exit(42);
}
printf("%d: fork()=%d\n", (int)getpid(), (int)pid);
sleep(1);
const int n = 10;
printf("SIGALRM x %d\n", n); fflush(stdout);
for (int i = 0; i < n; i++) {
sched_yield();
if (kill(pid, SIGALRM))
perror("SIGALRM");
}
printf("SIGSTOP\n"); fflush(stdout);
if (kill(pid, SIGSTOP))
perror("SIGSTOP");
printf("SIGTERM\n"); fflush(stdout);
if (kill(pid, SIGTERM))
perror("SIGTERM");
printf("SIGCONT\n"); fflush(stdout);
if (kill(pid, SIGCONT))
perror("SIGCONT");
printf("waitpid()...\n"); fflush(stdout);
int status = -1;
int wp = waitpid(pid, &status, 0);
printf("waidpid()=%d, status=0x%04x\n", wp, status);
return 0;
}
--
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
