Re: fork error when trying to call VirtualAlloc with size==0

I tried dlfork(FORK_NO_RELOAD) after dlopen() the proc macro DLLs. Now rustc works as expected. Therefore, I think the problem is most likely caused by too many DLLs loaded. See the PR here: https://github.com/rust-lang/rust/pull/141276 I think dlfork is a good workaround, but not the best. It wou

Re: fork error when trying to call VirtualAlloc with size==0

On 2025-05-19 21:25, Yuyi Wang via Cygwin wrote: Thank you for your reply. The DLL is a "proc macro" DLL for rustc, which means that it's not designed to be changed after created. However, I've also found that this stage-1 compiler doesn't always trigger this failure: it just trigger fork failure

Re: fork error when trying to call VirtualAlloc with size==0

Thank you for your reply. The DLL is a "proc macro" DLL for rustc, which means that it's not designed to be changed after created. However, I've also found that this stage-1 compiler doesn't always trigger this failure: it just trigger fork failure with compiling relatively large projects. In this

Re: smartmontools 7.5-1

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 -r ioctl,2 -i /dev/sda smartc

Re: fork error when trying to call VirtualAlloc with size==0

On Mon, 19 May 2025, Yuyi Wang via Cygwin wrote: > Recently I'm trying to build rustc on Cygwin (actually MSYS2). Here is the > error: > > 0 [main] rustc 3299 child_info_fork::abort: couldn't allocate memory > 0x1FD10(0) for > '\??\D:\Straw\Documents\Git\rust\build\x86_64-pc-cygwin\st

fork error when trying to call VirtualAlloc with size==0

Recently I'm trying to build rustc on Cygwin (actually MSYS2). Here is the error: 0 [main] rustc 3299 child_info_fork::abort: couldn't allocate memory 0x1FD10(0) for '\??\D:\Straw\Documents\Git\rust\build\x86_64-pc-cygwin\stage1-rustc\release\deps\zerovec_derive-4b870d338ef8cbdd.dll'

Crash or hang if SIGSEGV+SIGALRM are nested

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