On Sun, 25 May 2025 16:46:49 +0200, Christian Franke wrote:
On Sat, 24 May 2025 15:19:10 +0200, Christian Franke wrote:
If /proc/PID/maps is opened in parallel threads, the process PID may
segfault.
Testcase:
...
Problem is not reproducible with any of the other /proc/PID/* files.
A close
On Sat, 24 May 2025 15:19:10 +0200, Christian Franke wrote:
If /proc/PID/maps is opened in parallel threads, the process PID may
segfault.
Testcase:
$ uname -r
3.7.0-0.98.gb39b510c1ce6.x86_64
$ cat thrdopen.c
#include
#include
#include
#include
static const char * name;
static void *wor
If /proc/PID/maps is opened in parallel threads, the process PID may
segfault.
Testcase:
$ uname -r
3.7.0-0.98.gb39b510c1ce6.x86_64
$ cat thrdopen.c
#include
#include
#include
#include
static const char * name;
static void *worker(void *arg)
{
for (int i = 0; i < 1; i++) {
putc
Unexpected behavior of an uncommon use case:
$ uname -r
3.7.0-0.98.gb39b510c1ce6.x86_64
$ cygstart mintty - # Start second terminal
In second terminal:
$ echo $$; tty
1219
/dev/pty1
Back to first terminal:
$ dd of=/proc/1219/fd/1 <<<"Hello" # errno=EBADF
dd: error writing '/proc/1219/fd/1':
Eliot Moss via Cygwin wrote:
On 5/20/2025 9:44 AM, Christian Franke via Cygwin wrote:
Eliot Moss via Cygwin wrote:
On 5/20/2025 4:50 AM, Christian Franke via Cygwin wrote:
Eliot Moss via Cygwin wrote:
On 5/19/2025 9:14 AM, Christian Franke wrote:
The following package has been uploaded to
Eliot Moss via Cygwin wrote:
On 5/20/2025 4:50 AM, Christian Franke via Cygwin wrote:
Eliot Moss via Cygwin wrote:
On 5/19/2025 9:14 AM, Christian Franke wrote:
The following package has been uploaded to the Cygwin distribution:
* smartmontools-7.5-1
Thank you for this! It works fine on
Eliot Moss via Cygwin wrote:
On 5/19/2025 9:14 AM, Christian Franke wrote:
The following package has been uploaded to the Cygwin distribution:
* smartmontools-7.5-1
Thank you for this! It works fine on an attached HDD, but with my
built-in
NVMe, I get this, in response to /usr/sbin/smartctl
The attached testcase was originally intended to investigate why a
SIGSEGV from non-signal code could interrupt an already running signal
handler.
https://sourceware.org/pipermail/cygwin-patches/2025q2/013703.html
If run without strace, the testcase may crash silently (with exit status 0):
$ u
Found during check why SIGSEGV handler could interrupt SIGALRM handler
(which does not happen on Linux):
https://sourceware.org/pipermail/cygwin-patches/2025q2/013703.html
Testcase:
$ uname -r # Also occurs with 3.6.1-1.x86_64
3.7.0-0.95.g854150fda310.x86_64
$ cat sigsegv.c
int main()
{
*(vo
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 r
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
...
dep
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 a
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
P
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 j
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. St
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
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
#in
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);
Testcase for a minor issue:
$ > sparse_file
$ chattr +S sparse_file
$ dd if=/dev/zero bs=1M count=1 conv=sparse,notrunc of=sparse_file
...
$ lssparse sparse_file # OK
$ lssparse -H sparse_file # OK
Hole range[0]: offset=0x0, length=0x10
$ printf X >> sparse_file
$ lssparse sparse_fi
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
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",
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
#incl
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
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 foun
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 - <<<'
Corinna Vinschen via Cygwin wrote:
On Mar 12 17:06, Corinna Vinschen via Cygwin wrote:
On Mar 12 16:30, Corinna Vinschen via Cygwin wrote:
On Mar 11 12:32, Christian Franke via Cygwin wrote:
The attached testcase should test the following use cases of setcontext:
- call from regular user
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
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 swapco
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 cur
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
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
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&#x
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
116
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]
wast
Roland Mainz via Cygwin wrote:
Small issue with Cygwin 3.6 (3.6.0-0.419.g3c1308ed890e.x86_64) system
/usr/include/unistd.h and clang:
snip
$ clang --version
clang version 8.0.1 (tags/RELEASE_801/final)
Target: x86_64-unknown-windows-cygnus
Thread model: posix
InstalledDir: /usr/bin
$ cl
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: Per
Corinna Vinschen via Cygwin wrote:
[I sent this on 2024-02-14 to the cygwin-announce mailing list,
but forgot to CC the cygwin mailing list. Doing it now...]
Hi folks,
we're planning the next major release in the next few (hopefully
not more than two) weeks.
...
Below you'll find a list of c
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
Corinna Vinschen via Cygwin wrote:
...
I just deployed 0.12.2-2 as test. Apart from setproctitle{_init}, it
also drops exporting the following symbols already exported from Cygwin:
arc4random*
explicit_bzero
fpurge
getprogname
reallocarray
reallocf
setprognam
Corinna Vinschen via Cygwin wrote:
On Feb 19 16:37, Corinna Vinschen via Cygwin wrote:
On Feb 19 14:40, Corinna Vinschen via Cygwin wrote:
On Feb 19 14:25, Christian Franke via Cygwin wrote:
Corinna Vinschen via Cygwin wrote:
So I think we rather shouldn't supply the libbsd versi
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
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
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 on
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 f
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 thi
Christian Franke via Cygwin wrote:
Testcase:
$ uname -r
3.5.7-1.x86_64
$ cygcheck -f /bin/cp.exe
coreutils-9.6-1
$ for i in 1 2 3; do cat /bin/cygwin1.dll > file$i; done
$ compact /C file2 # NTFS compression
... (1.7 : 1) ...
$ compact /C /EXE:LZX file3 # Compact OS LZX compression
... (
Testcase:
$ uname -r
3.5.7-1.x86_64
$ cygcheck -f /bin/cp.exe
coreutils-9.6-1
$ for i in 1 2 3; do cat /bin/cygwin1.dll > file$i; done
$ compact /C file2 # NTFS compression
... (1.7 : 1) ...
$ compact /C /EXE:LZX file3 # Compact OS LZX compression
... (2.8 : 1) ...
$ stat -c '%b %s %n' file?
Brian Inglis via Cygwin wrote:
On 2025-02-09 08:01, Christian Franke via Cygwin wrote:
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
Corinna Vinschen via Cygwin wrote:
On Feb 12 17:32, Cedric Blancher via Cygwin wrote:
Good afternoon!
Is copying sparse files broken in 3.6.0-0.362.g68c13dc92f65.x86_64?
cp --version
cp (GNU coreutils) 9.5
Packaged by Cygwin (9.5-1
Checklist:
- Volume has FILE_SUPPORTS_SPARSE_FILES
- Cygwin m
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
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?
Thank
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
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
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
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
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
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_RD
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
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=61c2f075cd55d4a
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.
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
--
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):
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 THA
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
..
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=1e8c9
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 ter
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 proble
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
creat
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.
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)
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 wa
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:h
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
$ .
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: [619
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
./tes
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(&
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
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"); retur
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
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
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
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
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
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
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
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:
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
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
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 b
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
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
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
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
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
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 vers
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
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
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
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
Testcas
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_WA
1 - 100 of 121 matches
Mail list logo
