GHC issueshttps://gitlab.haskell.org/ghc/ghc/-/issues2019-07-07T19:03:42Zhttps://gitlab.haskell.org/ghc/ghc/-/issues/3473System.Posix.Semaphore shouldn't create finalizers with Foreign.newForeignPtr2019-07-07T19:03:42ZKari PahulaSystem.Posix.Semaphore shouldn't create finalizers with Foreign.newForeignPtrRunning this program
```
import System.Posix.Semaphore
main = do
s <- semOpen "c" (OpenSemFlags True False) 0666 1
semThreadWait s
v <- semGetValue s
putStrLn "Type!"
a <- getLine
putStrL...Running this program
```
import System.Posix.Semaphore
main = do
s <- semOpen "c" (OpenSemFlags True False) 0666 1
semThreadWait s
v <- semGetValue s
putStrLn "Type!"
a <- getLine
putStrLn $ "OK, " ++ a
semPost s
```
fails like this:
```
Type!
abc
OK, abc
sem: error: a C finalizer called back into Haskell.
This was previously allowed, but is disallowed in GHC 6.10.2 and later.
To create finalizers that may call back into Haskll, use
Foreign.Concurrent.newForeignPtr instead of Foreign.newForeignPtr.
```
The attached patch for libraries/unix/System/Posix/Semaphore.hsc should fix this.
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | -------------- |
| Version | 6.10.4 |
| Type | Bug |
| TypeOfFailure | OtherFailure |
| Priority | normal |
| Resolution | Unresolved |
| Component | libraries/unix |
| Test case | |
| Differential revisions | |
| BlockedBy | |
| Related | |
| Blocking | |
| CC | |
| Operating system | |
| Architecture | |
</details>
<!-- {"blocked_by":[],"summary":"System.Posix.Semaphore shouldn't create finalizers with Foreign.newForeignPtr","status":"New","operating_system":"","component":"libraries/unix","related":[],"milestone":"","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"6.10.4","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"Bug","description":"Running this program \r\n\r\n{{{\r\nimport System.Posix.Semaphore\r\n\r\nmain = do\r\n s <- semOpen \"c\" (OpenSemFlags True False) 0666 1\r\n semThreadWait s\r\n v <- semGetValue s\r\n putStrLn \"Type!\"\r\n a <- getLine\r\n putStrLn $ \"OK, \" ++ a\r\n semPost s\r\n}}}\r\n\r\nfails like this:\r\n\r\n{{{\r\nType!\r\nabc\r\nOK, abc\r\nsem: error: a C finalizer called back into Haskell.\r\nThis was previously allowed, but is disallowed in GHC 6.10.2 and later.\r\nTo create finalizers that may call back into Haskll, use\r\nForeign.Concurrent.newForeignPtr instead of Foreign.newForeignPtr.\r\n}}}\r\n\r\nThe attached patch for libraries/unix/System/Posix/Semaphore.hsc should fix this.\r\n","type_of_failure":"OtherFailure","blocking":[]} -->6.12.1Simon MarlowSimon Marlowhttps://gitlab.haskell.org/ghc/ghc/-/issues/24240Bump filepath to 1.4.200.1 and unix to 2.8.4.02024-02-08T17:32:03ZMatthew PickeringBump filepath to 1.4.200.1 and unix to 2.8.4.0The maintainer of filepath and unix has requested a bump of these libraries.
https://gitlab.haskell.org/ghc/ghc/-/issues/24017#note_537687The maintainer of filepath and unix has requested a bump of these libraries.
https://gitlab.haskell.org/ghc/ghc/-/issues/24017#note_5376879.6.4Matthew PickeringMatthew Pickeringhttps://gitlab.haskell.org/ghc/ghc/-/issues/22454macOS: semaphore related deprecation warnings when building compiler2023-02-07T17:15:08ZAlex DmacOS: semaphore related deprecation warnings when building compilerWhile building ghc stage 1, I noticed these warnings:
```
/var/folders/fw/n1sdyp616tz20jfs2h0qzngr0000gq/T/ghc57747_0/ghc_2.c:9:106: error:
warning: 'sem_getvalue' is deprecated [-Wdeprecated-declarations]
|
9 | HsInt ghczuwrapper...While building ghc stage 1, I noticed these warnings:
```
/var/folders/fw/n1sdyp616tz20jfs2h0qzngr0000gq/T/ghc57747_0/ghc_2.c:9:106: error:
warning: 'sem_getvalue' is deprecated [-Wdeprecated-declarations]
|
9 | HsInt ghczuwrapperZC0ZCunixzm2zi7zi3ZCSystemziPosixziSemaphoreZCsemzugetvalue(void* a1, int* a2) {return sem_getvalue(a1, a2);}
| ^
HsInt ghczuwrapperZC0ZCunixzm2zi7zi3ZCSystemziPosixziSemaphoreZCsemzugetvalue(void* a1, int* a2) {return sem_getvalue(a1, a2);}
^
/Library/Developer/CommandLineTools/SDKs/MacOSX.sdk/usr/include/sys/semaphore.h:54:56: error:
note: 'sem_getvalue' has been explicitly marked deprecated here
|
54 | int sem_getvalue(sem_t * __restrict, int * __restrict) __deprecated;
| ^
int sem_getvalue(sem_t * __restrict, int * __restrict) __deprecated;
^
/Library/Developer/CommandLineTools/SDKs/MacOSX.sdk/usr/include/sys/cdefs.h:196:40: error:
note: expanded from macro '__deprecated'
|
196 | #define __deprecated __attribute__((__deprecated__))
| ^
#define __deprecated __attribute__((__deprecated__))
^
1 warning generated.
/var/folders/fw/n1sdyp616tz20jfs2h0qzngr0000gq/T/ghc57747_0/ghc_8.c:9:106: error:
warning: 'sem_getvalue' is deprecated [-Wdeprecated-declarations]
|
9 | HsInt ghczuwrapperZC0ZCunixzm2zi7zi3ZCSystemziPosixziSemaphoreZCsemzugetvalue(void* a1, int* a2) {return sem_getvalue(a1, a2);}
| ^
HsInt ghczuwrapperZC0ZCunixzm2zi7zi3ZCSystemziPosixziSemaphoreZCsemzugetvalue(void* a1, int* a2) {return sem_getvalue(a1, a2);}
^
/Library/Developer/CommandLineTools/SDKs/MacOSX.sdk/usr/include/sys/semaphore.h:54:56: error:
note: 'sem_getvalue' has been explicitly marked deprecated here
|
54 | int sem_getvalue(sem_t * __restrict, int * __restrict) __deprecated;
| ^
int sem_getvalue(sem_t * __restrict, int * __restrict) __deprecated;
^
/Library/Developer/CommandLineTools/SDKs/MacOSX.sdk/usr/include/sys/cdefs.h:196:40: error:
note: expanded from macro '__deprecated'
|
196 | #define __deprecated __attribute__((__deprecated__))
| ^
#define __deprecated __attribute__((__deprecated__))
^
1 warning generated.
```
macOS 12.5.1 (aarch64)https://gitlab.haskell.org/ghc/ghc/-/issues/19525getGroupEntryForName gives different result on WSL22021-04-06T14:45:03ZSimon Peyton JonesgetGroupEntryForName gives different result on WSL2I’ve just installed WSL2 and built GHC.
I get this (single) validation failure in libraries/unix/tests/getGroupEntryForName. It seems to be just an error message wibble, but I can’t push a change to master because that’ll affect everyon...I’ve just installed WSL2 and built GHC.
I get this (single) validation failure in libraries/unix/tests/getGroupEntryForName. It seems to be just an error message wibble, but I can’t push a change to master because that’ll affect everyone else.
Any ideas?
```
=====> 1 of 1 [0, 0, 0]
]0;getGroupEntryForName(normal) 1 of 1 [0, 0, 0]Actual stderr output differs from expected:
--- getGroupEntryForName.run/getGroupEntryForName.stderr.normalised 2021-03-09 22:36:01.300421100 +0000
+++ getGroupEntryForName.run/getGroupEntryForName.run.stderr.normalised 2021-03-09 22:36:01.300421100 +0000
@@ -1 +1 @@
-getGroupEntryForName: getGroupEntryForName: does not exist (no such group)
+getGroupEntryForName: getGroupEntryForName: does not exist (No such process)
*** unexpected failure for getGroupEntryForName(normal)
```
For info, about my system:
```
bash$ uname -a
Linux MSRC-3645512 5.4.72-microsoft-standard-WSL2 #1 SMP Wed Oct 28 23:40:43 UTC 2020 x86_64 x86_64 x86_64 GNU/Linux
bash$ cat /etc/os-release
NAME="Ubuntu"
VERSION="20.04.2 LTS (Focal Fossa)"
ID=ubuntu
ID_LIKE=debian
PRETTY_NAME="Ubuntu 20.04.2 LTS"
VERSION_ID="20.04"
HOME_URL="https://www.ubuntu.com/"
SUPPORT_URL="https://help.ubuntu.com/"
BUG_REPORT_URL="https://bugs.launchpad.net/ubuntu/"
PRIVACY_POLICY_URL="https://www.ubuntu.com/legal/terms-and-policies/privacy-policy"
VERSION_CODENAME=focal
UBUNTU_CODENAME=focal
```https://gitlab.haskell.org/ghc/ghc/-/issues/16099expose st_blksize field from fstat syscall2019-07-07T18:01:31ZPhilippeexpose st_blksize field from fstat syscallThe libc manual talks about buffer sizes.
https://www.gnu.org/software/libc/manual/html_node/Controlling-Buffering.html
They advise:
Actually, you can get an even better value to use for the buffer size by means of the fstat system cal...The libc manual talks about buffer sizes.
https://www.gnu.org/software/libc/manual/html_node/Controlling-Buffering.html
They advise:
Actually, you can get an even better value to use for the buffer size by means of the fstat system call: it is found in the st_blksize field of the file attributes. See Attribute Meanings.
It's just that the st_blksize field it stepped over in the haskell definition of it:
https://github.com/haskell/unix/blob/8d188ed8067af17dfcc2cd6cbbfda7294ba17e17/System/Posix/Files/Common.hsc\#L280-L283
Which goes directly from filesize to accesstime
See also https://linux.die.net/man/2/fstat
Would be nice to expose the additional fields as well
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | -------------- |
| Version | 8.6.3 |
| Type | FeatureRequest |
| TypeOfFailure | OtherFailure |
| Priority | low |
| Resolution | Unresolved |
| Component | libraries/unix |
| Test case | |
| Differential revisions | |
| BlockedBy | |
| Related | |
| Blocking | |
| CC | |
| Operating system | |
| Architecture | |
</details>
<!-- {"blocked_by":[],"summary":"expose st_blksize field from fstat syscall","status":"New","operating_system":"","component":"libraries/unix","related":[],"milestone":"","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"8.6.3","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"FeatureRequest","description":"The libc manual talks about buffer sizes.\r\n\r\nhttps://www.gnu.org/software/libc/manual/html_node/Controlling-Buffering.html\r\n\r\nThey advise:\r\nActually, you can get an even better value to use for the buffer size by means of the fstat system call: it is found in the st_blksize field of the file attributes. See Attribute Meanings.\r\n\r\nIt's just that the st_blksize field it stepped over in the haskell definition of it:\r\n\r\nhttps://github.com/haskell/unix/blob/8d188ed8067af17dfcc2cd6cbbfda7294ba17e17/System/Posix/Files/Common.hsc#L280-L283\r\n\r\nWhich goes directly from filesize to accesstime\r\n\r\nSee also https://linux.die.net/man/2/fstat\r\n\r\nWould be nice to expose the additional fields as well","type_of_failure":"OtherFailure","blocking":[]} -->https://gitlab.haskell.org/ghc/ghc/-/issues/11137configure is broken for the unix package2019-07-07T18:31:48Zpgjconfigure is broken for the unix packageA few weeks ago (around November 1, 2015), the FreeBSD builders started to fail building GHC-HEAD with an error message something like that:
```
[...]
/usr/home/ghc-builder/work/builder/tempbuild/build/libraries/unix/dist-install/build/...A few weeks ago (around November 1, 2015), the FreeBSD builders started to fail building GHC-HEAD with an error message something like that:
```
[...]
/usr/home/ghc-builder/work/builder/tempbuild/build/libraries/unix/dist-install/build/libHSunix-2.7.1.0-ghc7.11.20151126.so: undefined reference to `fdatasync'
collect2: error: ld returned 1 exit status
`gcc48' failed in phase `Linker'. (Exit code: 1)
ghc/ghc.mk:121: recipe for target 'ghc/stage2/build/tmp/ghc-stage2' failed
gmake[1]: *** [ghc/stage2/build/tmp/ghc-stage2] Error 1
Makefile:121: recipe for target 'all' failed
gmake: *** [all] Error 2
```
That is because `fdatasync(2)` is not implemented on FreeBSD. Apparently, it is handled in the respective file (`System/Posix/Unistd.hsc`), though it relies on the variable (`HAVE_FDATASYNC`) generated at the `configure` phase. But for some reason, the `configure` script of the `unix` package fails to detect this as it says the following:
```
"inplace/bin/ghc-cabal" configure libraries/unix dist-install "" --with-ghc="/usr/home/ghc-builder/work/builder/tempbuild/build/inplace/bin/ghc-stage1" --with-ghc-pkg="/usr/home/ghc-builder/work/builder/tempbuild/build/inplace/bin/ghc-pkg" --disable-library-for-ghci --enable-library-vanilla --enable-library-profiling --enable-shared --with-hscolour="/usr/local/bin/HsColour" --configure-option=CFLAGS="-Wall -fno-stack-protector -Werror=unused-but-set-variable -Wno-error=inline" --configure-option=LDFLAGS=" " --configure-option=CPPFLAGS=" " --gcc-options="-Wall -fno-stack-protector -Werror=unused-but-set-variable -Wno-error=inline " --configure-option=--with-iconv-includes="/usr/local/include" --configure-option=--with-iconv-libraries="/usr/local/lib" --configure-option=--with-gmp-includes="/usr/local/include" --configure-option=--with-gmp-libraries="/usr/local/lib" --with-gcc="/usr/local/bin/gcc48" --with-ld="/usr/local/bin/ld" --configure-option=--with-cc="/usr/local/bin/gcc48" --with-ar="/usr/local/bin/ar" --with-alex="/usr/local/bin/alex" --with-happy="/usr/local/bin/happy"
Configuring unix-2.7.1.0...
[...]
checking for fdatasync... yes
```
That is the corresponding part of the `config.log`:
```
configure:4242: checking for fdatasync
configure:4263: /usr/local/bin/gcc48 -c -Wall -fno-stack-protector -Werror=unused-but-set-variable -Wno-error=inline conftest.c >&5
conftest.c: In function 'main':
conftest.c:71:1: warning: implicit declaration of function 'fdatasync' [-Wimplicit-function-declaration]
fdatasync(4);
^
configure:4263: $? = 0
configure:4271: result: yes
```
Looks like GCC is willing to compile the test code, although it notes that it cannot find the declaration of the `fdatasync()` function. Unfortunately, the `configure` script does not instruct GCC to do any linking or be serious on such warnings, so it happily proceeds.
For the reference, previously the `config.log` said something like that instead:
```
configure:4230: checking for fdatasync
configure:4230: /usr/local/bin/gcc48 -o conftest -Wall -fno-stack-protector -Werror=unused-but-set-variable -Wno-error=inline conftest.c >&5
/tmp//ccDCjZtO.o: In function `main':
conftest.c:(.text+0xa): undefined reference to `fdatasync'
collect2: error: ld returned 1 exit status
configure:4230: $? = 1
[...]
```
I am inclined to think that this is caused by the commit [b06446edd4753f964a46d27ddae864fad97adc13](https://github.com/haskell/unix/commit/b06446edd4753f964a46d27ddae864fad97adc13) for the `unix` package. Perhaps the following change can fix that, at least it fixed for me:
```
--- a/mk/warnings.mk
+++ b/mk/warnings.mk
@@ -16,6 +16,7 @@ SRC_CC_WARNING_OPTS += -Werror=unused-but-set-variable
endif
# gcc 4.6 gives 3 warning for giveCapabilityToTask not being inlined
SRC_CC_WARNING_OPTS += -Wno-error=inline
+SRC_CC_WARNING_OPTS += -Werror=implicit-function-declaration
endif
else
```
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | -------------- |
| Version | 7.11 |
| Type | Bug |
| TypeOfFailure | OtherFailure |
| Priority | normal |
| Resolution | Unresolved |
| Component | libraries/unix |
| Test case | |
| Differential revisions | |
| BlockedBy | |
| Related | |
| Blocking | |
| CC | |
| Operating system | |
| Architecture | |
</details>
<!-- {"blocked_by":[],"summary":"configure is broken for the unix package","status":"New","operating_system":"","component":"libraries/unix","related":[],"milestone":"","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"7.11","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"Bug","description":"A few weeks ago (around November 1, 2015), the FreeBSD builders started to fail building GHC-HEAD with an error message something like that:\r\n\r\n{{{\r\n[...]\r\n/usr/home/ghc-builder/work/builder/tempbuild/build/libraries/unix/dist-install/build/libHSunix-2.7.1.0-ghc7.11.20151126.so: undefined reference to `fdatasync'\r\ncollect2: error: ld returned 1 exit status\r\n`gcc48' failed in phase `Linker'. (Exit code: 1)\r\nghc/ghc.mk:121: recipe for target 'ghc/stage2/build/tmp/ghc-stage2' failed\r\ngmake[1]: *** [ghc/stage2/build/tmp/ghc-stage2] Error 1\r\nMakefile:121: recipe for target 'all' failed\r\ngmake: *** [all] Error 2\r\n}}}\r\n\r\nThat is because {{{fdatasync(2)}}} is not implemented on FreeBSD. Apparently, it is handled in the respective file ({{{System/Posix/Unistd.hsc}}}), though it relies on the variable ({{{HAVE_FDATASYNC}}}) generated at the {{{configure}}} phase. But for some reason, the {{{configure}}} script of the {{{unix}}} package fails to detect this as it says the following:\r\n\r\n{{{\r\n\"inplace/bin/ghc-cabal\" configure libraries/unix dist-install \"\" --with-ghc=\"/usr/home/ghc-builder/work/builder/tempbuild/build/inplace/bin/ghc-stage1\" --with-ghc-pkg=\"/usr/home/ghc-builder/work/builder/tempbuild/build/inplace/bin/ghc-pkg\" --disable-library-for-ghci --enable-library-vanilla --enable-library-profiling --enable-shared --with-hscolour=\"/usr/local/bin/HsColour\" --configure-option=CFLAGS=\"-Wall -fno-stack-protector -Werror=unused-but-set-variable -Wno-error=inline\" --configure-option=LDFLAGS=\" \" --configure-option=CPPFLAGS=\" \" --gcc-options=\"-Wall -fno-stack-protector -Werror=unused-but-set-variable -Wno-error=inline \" --configure-option=--with-iconv-includes=\"/usr/local/include\" --configure-option=--with-iconv-libraries=\"/usr/local/lib\" --configure-option=--with-gmp-includes=\"/usr/local/include\" --configure-option=--with-gmp-libraries=\"/usr/local/lib\" --with-gcc=\"/usr/local/bin/gcc48\" --with-ld=\"/usr/local/bin/ld\" --configure-option=--with-cc=\"/usr/local/bin/gcc48\" --with-ar=\"/usr/local/bin/ar\" --with-alex=\"/usr/local/bin/alex\" --with-happy=\"/usr/local/bin/happy\"\r\nConfiguring unix-2.7.1.0...\r\n[...]\r\nchecking for fdatasync... yes\r\n}}}\r\n\r\nThat is the corresponding part of the {{{config.log}}}:\r\n\r\n{{{\r\nconfigure:4242: checking for fdatasync\r\nconfigure:4263: /usr/local/bin/gcc48 -c -Wall -fno-stack-protector -Werror=unused-but-set-variable -Wno-error=inline conftest.c >&5\r\nconftest.c: In function 'main':\r\nconftest.c:71:1: warning: implicit declaration of function 'fdatasync' [-Wimplicit-function-declaration]\r\n fdatasync(4);\r\n ^\r\nconfigure:4263: $? = 0\r\nconfigure:4271: result: yes\r\n}}}\r\n\r\nLooks like GCC is willing to compile the test code, although it notes that it cannot find the declaration of the {{{fdatasync()}}} function. Unfortunately, the {{{configure}}} script does not instruct GCC to do any linking or be serious on such warnings, so it happily proceeds.\r\n\r\nFor the reference, previously the {{{config.log}}} said something like that instead:\r\n\r\n{{{\r\nconfigure:4230: checking for fdatasync\r\nconfigure:4230: /usr/local/bin/gcc48 -o conftest -Wall -fno-stack-protector -Werror=unused-but-set-variable -Wno-error=inline conftest.c >&5\r\n/tmp//ccDCjZtO.o: In function `main':\r\nconftest.c:(.text+0xa): undefined reference to `fdatasync'\r\ncollect2: error: ld returned 1 exit status\r\nconfigure:4230: $? = 1\r\n[...]\r\n}}}\r\n\r\nI am inclined to think that this is caused by the commit [https://github.com/haskell/unix/commit/b06446edd4753f964a46d27ddae864fad97adc13 b06446edd4753f964a46d27ddae864fad97adc13] for the {{{unix}}} package. Perhaps the following change can fix that, at least it fixed for me:\r\n\r\n{{{\r\n--- a/mk/warnings.mk\r\n+++ b/mk/warnings.mk\r\n@@ -16,6 +16,7 @@ SRC_CC_WARNING_OPTS += -Werror=unused-but-set-variable\r\n endif\r\n # gcc 4.6 gives 3 warning for giveCapabilityToTask not being inlined\r\n SRC_CC_WARNING_OPTS += -Wno-error=inline\r\n+SRC_CC_WARNING_OPTS += -Werror=implicit-function-declaration\r\n endif\r\n \r\n else\r\n}}}\r\n\r\n","type_of_failure":"OtherFailure","blocking":[]} -->8.0.1https://gitlab.haskell.org/ghc/ghc/-/issues/10081SIGTERM ignored when process has been detached from terminal2019-07-07T18:37:37ZnakalSIGTERM ignored when process has been detached from terminalI've tried to write a simple Unix daemon that reacts to signals. Here is the reduced source code sample:
```hs
import Control.Concurrent
import Control.Monad
import System.Exit
import System.IO
import System.Posix.Signals
loop = foreve...I've tried to write a simple Unix daemon that reacts to signals. Here is the reduced source code sample:
```hs
import Control.Concurrent
import Control.Monad
import System.Exit
import System.IO
import System.Posix.Signals
loop = forever $ threadDelay 1000000
main = do
ppid <- myThreadId
mapM (\sig -> installHandler sig (Catch $ trap ppid) Nothing)
[ lostConnection, keyboardSignal, softwareTermination, openEndedPipe ]
loop
trap tid = do
hPutStrLn stderr "Signal received.\n"
throwTo tid ExitSuccess
```
Such daemons usually run in background without a terminal attached. I verified that I can kill the process after being started on the terminal:
```
> ./daemon
Signal received.
```
With:
```
> killall daemon
```
in other terminal.
Other test, when I run it in background:
```
> ./daemon
(press Ctrl+Z)
> bg
> killall daemon
Signal received.
```
This case is also ok. Now the third test which is also OK:
```
> ./daemon > log 2>&1
(press Ctrl+Z)
> bg
> exit
```
In second terminal:
```
> cat log
> killall daemon
> cat log
Signal received.
> killall daemon
No matching processes belonging to you were found
```
Now the fourth test which is simply without a log file and this one fails:
```
> ./daemon
(press Ctrl+Z)
> bg
> exit
```
On some other terminal try to kill the process:
```
> killall xxx
> killall xxx
> killall xxx
> killall -9 xxx
> killall xxx
No matching processes belonging to you were found
```
Signal 9 (SIGKILL) kills the process hard without the signal trap. That's why it works, of course, but SIGTERM is being ignored for some reason. Maybe I am forgetting something, but in my opinion this should end the process properly, too.
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | -------------- |
| Version | 7.8.3 |
| Type | Bug |
| TypeOfFailure | OtherFailure |
| Priority | normal |
| Resolution | Unresolved |
| Component | libraries/unix |
| Test case | |
| Differential revisions | |
| BlockedBy | |
| Related | |
| Blocking | |
| CC | |
| Operating system | FreeBSD |
| Architecture | |
</details>
<!-- {"blocked_by":[],"summary":"SIGTERM ignored when process has been detached from terminal","status":"New","operating_system":"FreeBSD","component":"libraries/unix","related":[],"milestone":"","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"7.8.3","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"Bug","description":"I've tried to write a simple Unix daemon that reacts to signals. Here is the reduced source code sample:\r\n\r\n{{{#!hs\r\nimport Control.Concurrent\r\nimport Control.Monad\r\nimport System.Exit\r\nimport System.IO\r\nimport System.Posix.Signals\r\n\r\nloop = forever $ threadDelay 1000000\r\n\r\nmain = do\r\n ppid <- myThreadId\r\n mapM (\\sig -> installHandler sig (Catch $ trap ppid) Nothing)\r\n [ lostConnection, keyboardSignal, softwareTermination, openEndedPipe ]\r\n loop\r\n\r\ntrap tid = do\r\n hPutStrLn stderr \"Signal received.\\n\"\r\n throwTo tid ExitSuccess\r\n}}}\r\n\r\nSuch daemons usually run in background without a terminal attached. I verified that I can kill the process after being started on the terminal:\r\n\r\n{{{\r\n> ./daemon\r\nSignal received.\r\n}}}\r\n\r\nWith:\r\n{{{\r\n> killall daemon\r\n}}}\r\n\r\nin other terminal.\r\n\r\nOther test, when I run it in background:\r\n{{{\r\n> ./daemon\r\n(press Ctrl+Z)\r\n> bg\r\n> killall daemon\r\nSignal received.\r\n}}}\r\n\r\nThis case is also ok. Now the third test which is also OK:\r\n\r\n{{{\r\n> ./daemon > log 2>&1\r\n(press Ctrl+Z)\r\n> bg\r\n> exit\r\n}}}\r\n\r\nIn second terminal:\r\n{{{\r\n> cat log\r\n> killall daemon\r\n> cat log\r\nSignal received.\r\n\r\n> killall daemon\r\nNo matching processes belonging to you were found\r\n}}}\r\n\r\nNow the fourth test which is simply without a log file and this one fails:\r\n{{{\r\n> ./daemon\r\n(press Ctrl+Z)\r\n> bg\r\n> exit\r\n}}}\r\n\r\nOn some other terminal try to kill the process:\r\n{{{ \r\n> killall xxx\r\n> killall xxx\r\n> killall xxx\r\n> killall -9 xxx\r\n> killall xxx\r\nNo matching processes belonging to you were found\r\n}}}\r\n\r\nSignal 9 (SIGKILL) kills the process hard without the signal trap. That's why it works, of course, but SIGTERM is being ignored for some reason. Maybe I am forgetting something, but in my opinion this should end the process properly, too.","type_of_failure":"OtherFailure","blocking":[]} -->Edward KmettEdward Kmetthttps://gitlab.haskell.org/ghc/ghc/-/issues/9393execvpe should handle ENOTDIR2019-07-07T18:40:35Ziquiwexecvpe should handle ENOTDIRIf PATH environment variable contains non directory component,
execvpe fails by ENOTDIR.
For example, if "/tmp/foo" is a regular file, the following program fails with PATH contains "/tmp/foo".
```
module Main where
import System.Envi...If PATH environment variable contains non directory component,
execvpe fails by ENOTDIR.
For example, if "/tmp/foo" is a regular file, the following program fails with PATH contains "/tmp/foo".
```
module Main where
import System.Environment
import System.Posix.Process
main :: IO ()
main = do
env <- getEnvironment
executeFile "echo" True [] (Just env)
return ()
```
```
$ PATH=/tmp/foo:$PATH runghc a.hs
a.hs: echo: executeFile: inappropriate type (Not a directory)
```
See for example, https://github.com/haskell/cabal/issues/1723
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | -------------- |
| Version | 7.8.2 |
| Type | Bug |
| TypeOfFailure | OtherFailure |
| Priority | normal |
| Resolution | Unresolved |
| Component | libraries/unix |
| Test case | |
| Differential revisions | |
| BlockedBy | |
| Related | |
| Blocking | |
| CC | |
| Operating system | |
| Architecture | |
</details>
<!-- {"blocked_by":[],"summary":"execvpe should handle ENOTDIR","status":"New","operating_system":"","component":"libraries/unix","related":[],"milestone":"","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"7.8.2","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"Bug","description":"If PATH environment variable contains non directory component,\r\nexecvpe fails by ENOTDIR.\r\n\r\nFor example, if \"/tmp/foo\" is a regular file, the following program fails with PATH contains \"/tmp/foo\".\r\n{{{\r\nmodule Main where\r\n\r\nimport System.Environment\r\nimport System.Posix.Process\r\n\r\nmain :: IO ()\r\nmain = do\r\n env <- getEnvironment\r\n executeFile \"echo\" True [] (Just env)\r\n return ()\r\n}}}\r\n\r\n{{{\r\n$ PATH=/tmp/foo:$PATH runghc a.hs \r\na.hs: echo: executeFile: inappropriate type (Not a directory)\r\n}}}\r\n\r\nSee for example, https://github.com/haskell/cabal/issues/1723","type_of_failure":"OtherFailure","blocking":[]} -->7.10.1https://gitlab.haskell.org/ghc/ghc/-/issues/8902Test for RTLD_NEXT, RTLD_DEFAULT broken on Linux2019-07-07T18:42:53ZPeter Trommlerptrommler@acm.orgTest for RTLD_NEXT, RTLD_DEFAULT broken on LinuxBuilding 7.8.1RC2 on openSUSE, I see this:
```
[ 2270s] checking return type of unsetenv... int
[ 2270s] checking for RTLD_NEXT from dlfcn.h... no
[ 2270s] checking for RTLD_DEFAULT from dlfcn.h... no
[ 2270s] checking for RTLD_LOCAL fr...Building 7.8.1RC2 on openSUSE, I see this:
```
[ 2270s] checking return type of unsetenv... int
[ 2270s] checking for RTLD_NEXT from dlfcn.h... no
[ 2270s] checking for RTLD_DEFAULT from dlfcn.h... no
[ 2270s] checking for RTLD_LOCAL from dlfcn.h... yes
```
The manual says that both RTLD_NEXT and RTLD_DEFAULT exist.
Setting priority to low as I don't see any failures because of that.
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | -------------- |
| Version | 7.8.1-rc2 |
| Type | Bug |
| TypeOfFailure | OtherFailure |
| Priority | low |
| Resolution | Unresolved |
| Component | libraries/unix |
| Test case | |
| Differential revisions | |
| BlockedBy | |
| Related | |
| Blocking | |
| CC | |
| Operating system | |
| Architecture | |
</details>
<!-- {"blocked_by":[],"summary":"Test for RTLD_NEXT, RTLD_DEFAULT broken on Linux","status":"New","operating_system":"","component":"libraries/unix","related":[],"milestone":"","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"7.8.1-rc2","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"Bug","description":"Building 7.8.1RC2 on openSUSE, I see this:\r\n{{{\r\n[ 2270s] checking return type of unsetenv... int\r\n[ 2270s] checking for RTLD_NEXT from dlfcn.h... no\r\n[ 2270s] checking for RTLD_DEFAULT from dlfcn.h... no\r\n[ 2270s] checking for RTLD_LOCAL from dlfcn.h... yes\r\n}}}\r\n\r\nThe manual says that both RTLD_NEXT and RTLD_DEFAULT exist.\r\n\r\nSetting priority to low as I don't see any failures because of that.","type_of_failure":"OtherFailure","blocking":[]} -->https://gitlab.haskell.org/ghc/ghc/-/issues/8859import conditionalization in System.Posix.Files.Common is wrong2019-07-07T18:43:04Zrwbartonimport conditionalization in System.Posix.Files.Common is wrong`System/Posix/Files/Common.hsc` imports `Data.Int` and `Data.Ratio` conditionally, to avoid "unused import" compiler warnings:
```
#if defined(HAVE_STRUCT_STAT_ST_CTIM) || \
defined(HAVE_STRUCT_STAT_ST_MTIM) || \
defined(HAVE_ST...`System/Posix/Files/Common.hsc` imports `Data.Int` and `Data.Ratio` conditionally, to avoid "unused import" compiler warnings:
```
#if defined(HAVE_STRUCT_STAT_ST_CTIM) || \
defined(HAVE_STRUCT_STAT_ST_MTIM) || \
defined(HAVE_STRUCT_STAT_ST_ATIM) || \
defined(HAVE_STRUCT_STAT_ST_ATIMESPEC) || \
defined(HAVE_STRUCT_STAT_ST_MTIMESPEC) || \
defined(HAVE_STRUCT_STAT_ST_CTIMESPEC)
import Data.Int
import Data.Ratio
#endif
```
but those modules are actually used in functions like
```
accessTimeHiRes (FileStatus stat) =
unsafePerformIO $ withForeignPtr stat $ \stat_ptr -> do
sec <- (#peek struct stat, st_atime) stat_ptr :: IO EpochTime
#ifdef HAVE_STRUCT_STAT_ST_ATIM
nsec <- (#peek struct stat, st_atim.tv_nsec) stat_ptr :: IO (#type long)
let frac = toInteger nsec % 10^(9::Int)
#elif HAVE_STRUCT_STAT_ST_ATIMESPEC
nsec <- (#peek struct stat, st_atimespec.tv_nsec) stat_ptr :: IO (#type long)
let frac = toInteger nsec % 10^(9::Int)
#elif HAVE_STRUCT_STAT_ST_ATIMENSEC
nsec <- (#peek struct stat, st_atimensec) stat_ptr :: IO (#type long)
let frac = toInteger nsec % 10^(9::Int)
#elif HAVE_STRUCT_STAT_ST_ATIME_N
nsec <- (#peek struct stat, st_atime_n) stat_ptr :: IO (#type int)
let frac = toInteger nsec % 10^(9::Int)
#elif HAVE_STRUCT_STAT_ST_UATIME
usec <- (#peek struct stat, st_uatime) stat_ptr :: IO (#type int)
let frac = toInteger usec % 10^(6::Int)
#else
let frac = 0
#endif
return $ fromRational $ toRational sec + frac
```
so there should be additional tests for `defined(HAVE_STRUCT_STAT_ST_ATIMENSEC)`, `defined(HAVE_STRUCT_STAT_ST_ATIME_N)`, ... (15 total).
Or, maybe there's a better alternative, since this is very long-winded and fragile...
This breaks the build on Android, which has `st_atimensec`.
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | -------------- |
| Version | 7.8.1-rc2 |
| Type | Bug |
| TypeOfFailure | OtherFailure |
| Priority | normal |
| Resolution | Unresolved |
| Component | libraries/unix |
| Test case | |
| Differential revisions | |
| BlockedBy | |
| Related | |
| Blocking | |
| CC | |
| Operating system | |
| Architecture | |
</details>
<!-- {"blocked_by":[],"summary":"import conditionalization in System.Posix.Files.Common is wrong","status":"New","operating_system":"","component":"libraries/unix","related":[],"milestone":"","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"7.8.1-rc2","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"Bug","description":"`System/Posix/Files/Common.hsc` imports `Data.Int` and `Data.Ratio` conditionally, to avoid \"unused import\" compiler warnings:\r\n\r\n{{{\r\n#if defined(HAVE_STRUCT_STAT_ST_CTIM) || \\\r\n defined(HAVE_STRUCT_STAT_ST_MTIM) || \\\r\n defined(HAVE_STRUCT_STAT_ST_ATIM) || \\\r\n defined(HAVE_STRUCT_STAT_ST_ATIMESPEC) || \\\r\n defined(HAVE_STRUCT_STAT_ST_MTIMESPEC) || \\\r\n defined(HAVE_STRUCT_STAT_ST_CTIMESPEC)\r\nimport Data.Int\r\nimport Data.Ratio\r\n#endif\r\n}}}\r\n\r\nbut those modules are actually used in functions like\r\n\r\n{{{\r\naccessTimeHiRes (FileStatus stat) =\r\n unsafePerformIO $ withForeignPtr stat $ \\stat_ptr -> do\r\n sec <- (#peek struct stat, st_atime) stat_ptr :: IO EpochTime\r\n#ifdef HAVE_STRUCT_STAT_ST_ATIM\r\n nsec <- (#peek struct stat, st_atim.tv_nsec) stat_ptr :: IO (#type long)\r\n let frac = toInteger nsec % 10^(9::Int)\r\n#elif HAVE_STRUCT_STAT_ST_ATIMESPEC\r\n nsec <- (#peek struct stat, st_atimespec.tv_nsec) stat_ptr :: IO (#type long)\r\n let frac = toInteger nsec % 10^(9::Int)\r\n#elif HAVE_STRUCT_STAT_ST_ATIMENSEC\r\n nsec <- (#peek struct stat, st_atimensec) stat_ptr :: IO (#type long)\r\n let frac = toInteger nsec % 10^(9::Int)\r\n#elif HAVE_STRUCT_STAT_ST_ATIME_N\r\n nsec <- (#peek struct stat, st_atime_n) stat_ptr :: IO (#type int)\r\n let frac = toInteger nsec % 10^(9::Int)\r\n#elif HAVE_STRUCT_STAT_ST_UATIME\r\n usec <- (#peek struct stat, st_uatime) stat_ptr :: IO (#type int)\r\n let frac = toInteger usec % 10^(6::Int)\r\n#else\r\n let frac = 0\r\n#endif\r\n return $ fromRational $ toRational sec + frac\r\n}}}\r\n\r\nso there should be additional tests for `defined(HAVE_STRUCT_STAT_ST_ATIMENSEC)`, `defined(HAVE_STRUCT_STAT_ST_ATIME_N)`, ... (15 total).\r\n\r\nOr, maybe there's a better alternative, since this is very long-winded and fragile...\r\n\r\nThis breaks the build on Android, which has `st_atimensec`.","type_of_failure":"OtherFailure","blocking":[]} -->8.0.1Herbert Valerio Riedelhvr@gnu.orgHerbert Valerio Riedelhvr@gnu.orghttps://gitlab.haskell.org/ghc/ghc/-/issues/8741`System.Directory.getPermissions` fails on read-only filesystem2019-07-07T18:43:42ZHerbert Valerio Riedelhvr@gnu.org`System.Directory.getPermissions` fails on read-only filesystemAlain O'Dea reports in an [email](http://permalink.gmane.org/gmane.comp.lang.haskell.libraries/21078) that:
```
Prelude> System.Directory.getPermissions "/usr/bin/ld"
*** Exception: /usr/bin/ld: fileAccess: permission denied (Read-only ...Alain O'Dea reports in an [email](http://permalink.gmane.org/gmane.comp.lang.haskell.libraries/21078) that:
```
Prelude> System.Directory.getPermissions "/usr/bin/ld"
*** Exception: /usr/bin/ld: fileAccess: permission denied (Read-only file system)
```
> That seems wrong.
>
> An `access(*, W_OK)` syscall by design should return `EROFS` on a read-only file system by specification.
>
> This breaks Cabal on SmartOS since `/usr` is read-only by design and Cabal calls `getPermissions "/usr/bin/ld"`.
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | ------------------- |
| Version | 7.6.3 |
| Type | Bug |
| TypeOfFailure | OtherFailure |
| Priority | high |
| Resolution | Unresolved |
| Component | libraries/directory |
| Test case | |
| Differential revisions | |
| BlockedBy | |
| Related | |
| Blocking | |
| CC | |
| Operating system | |
| Architecture | |
</details>
<!-- {"blocked_by":[],"summary":"`System.Directory.getPermissions` fails on read-only filesystem","status":"New","operating_system":"","component":"libraries/directory","related":[],"milestone":"","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"7.6.3","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"Bug","description":"Alain O'Dea reports in an [http://permalink.gmane.org/gmane.comp.lang.haskell.libraries/21078 email] that:\r\n\r\n{{{\r\nPrelude> System.Directory.getPermissions \"/usr/bin/ld\"\r\n*** Exception: /usr/bin/ld: fileAccess: permission denied (Read-only file system)\r\n}}}\r\n> That seems wrong.\r\n>\r\n> An `access(*, W_OK)` syscall by design should return `EROFS` on a read-only file system by specification.\r\n>\r\n> This breaks Cabal on SmartOS since `/usr` is read-only by design and Cabal calls `getPermissions \"/usr/bin/ld\"`.","type_of_failure":"OtherFailure","blocking":[]} -->7.8.1AlainODeaAlainODeahttps://gitlab.haskell.org/ghc/ghc/-/issues/8713Avoid libraries if unneeded (librt, libdl, libpthread)2019-07-07T18:43:49Zip1981Avoid libraries if unneeded (librt, libdl, libpthread)I have GHC on an unusual system \[1\]
libdl.so.1, librt.so.1 and some others are "filter libraries": they do not provide real functions (almost all is in libc.so.1), but to make thing work libFOO.so are GNU ld linker scripts: thus linki...I have GHC on an unusual system \[1\]
libdl.so.1, librt.so.1 and some others are "filter libraries": they do not provide real functions (almost all is in libc.so.1), but to make thing work libFOO.so are GNU ld linker scripts: thus linking is successful, libFOO.so.1 is not linked in :-)
Unfortunately, runtime linker (ld.so.1) does not understand GNU ld linker scripts. And I get errors like this:
```
# ghci -package unix
GHCi, version 7.6.3: http://www.haskell.org/ghc/ :? for help
Loading package ghc-prim ... linking ... done.
Loading package integer-gmp ... linking ... done.
Loading package base ... linking ... done.
Loading package array-0.4.0.1 ... linking ... done.
Loading package deepseq-1.3.0.1 ... linking ... done.
Loading package bytestring-0.10.0.2 ... linking ... done.
Loading package old-locale-1.0.0.5 ... linking ... done.
Loading package time-1.4.0.1 ... linking ... done.
Loading package unix-2.7.0.0 ... <command line>: can't load .so/.DLL for: /usr/lib/gcc/x86_64-pc-solaris2.11/4.7/../../../x86_64-illumos/libdl.so (ld.so.1: ghc: fatal: /usr/lib/gcc/x86_64-pc-solaris2.11/4.7/../../../x86_64-illumos/libdl.so: unknown file type)
```
The unix package v2.6 had the same issue with librt.so too, in version 2.7 libdl.so remains.
I use the attached patch for GHC 7.6.3 to fix this issue.
In general I suggest to use AC_SEARCH_LIBS instead of AC_CHECK_LIB
\[1\] http://osdyson.org
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | -------------- |
| Version | 7.6.3 |
| Type | Bug |
| TypeOfFailure | GhcDoesn'tWork |
| Priority | normal |
| Resolution | Unresolved |
| Component | libraries/unix |
| Test case | |
| Differential revisions | |
| BlockedBy | |
| Related | |
| Blocking | |
| CC | |
| Operating system | |
| Architecture | |
</details>
<!-- {"blocked_by":[],"summary":"libdl, libpthread may be unwanted too","status":"New","operating_system":"","component":"libraries/unix","related":[],"milestone":"","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"7.6.3","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"Bug","description":"I have GHC on an unusual system [1]\r\n\r\nlibdl.so.1, librt.so.1 and some others are \"filter libraries\": they do not provide real functions (almost all is in libc.so.1), but to make thing work libFOO.so are GNU ld linker scripts: thus linking is successful, libFOO.so.1 is not linked in :-)\r\n\r\nUnfortunately, runtime linker (ld.so.1) does not understand GNU ld linker scripts. And I get errors like this:\r\n\r\n{{{\r\n# ghci -package unix\r\nGHCi, version 7.6.3: http://www.haskell.org/ghc/ :? for help\r\nLoading package ghc-prim ... linking ... done.\r\nLoading package integer-gmp ... linking ... done.\r\nLoading package base ... linking ... done.\r\nLoading package array-0.4.0.1 ... linking ... done.\r\nLoading package deepseq-1.3.0.1 ... linking ... done.\r\nLoading package bytestring-0.10.0.2 ... linking ... done.\r\nLoading package old-locale-1.0.0.5 ... linking ... done.\r\nLoading package time-1.4.0.1 ... linking ... done.\r\nLoading package unix-2.7.0.0 ... <command line>: can't load .so/.DLL for: /usr/lib/gcc/x86_64-pc-solaris2.11/4.7/../../../x86_64-illumos/libdl.so (ld.so.1: ghc: fatal: /usr/lib/gcc/x86_64-pc-solaris2.11/4.7/../../../x86_64-illumos/libdl.so: unknown file type)\r\n\r\n}}}\r\n\r\nThe unix package v2.6 had the same issue with librt.so too, in version 2.7 libdl.so remains.\r\n\r\nI use the attached patch for GHC 7.6.3 to fix this issue.\r\n\r\nIn general I suggest to use AC_SEARCH_LIBS instead of AC_CHECK_LIB\r\n\r\n[1] http://osdyson.org","type_of_failure":"GhcDoesn'tWork","blocking":[]} -->https://gitlab.haskell.org/ghc/ghc/-/issues/8621Pull request for inclusion in `unix' module of fsync(2), fdatasync(2), posix_...2019-07-07T18:44:14ZjimenezrickPull request for inclusion in `unix' module of fsync(2), fdatasync(2), posix_fadvise(2) and posix_fallocate(2)Discussion in the mailing list (I fixed both commented silly issues):
http://www.haskell.org/pipermail/libraries/2013-December/021756.html
Please review this pull request:
https://github.com/jimenezrick/unix/compare/master...file-utils....Discussion in the mailing list (I fixed both commented silly issues):
http://www.haskell.org/pipermail/libraries/2013-December/021756.html
Please review this pull request:
https://github.com/jimenezrick/unix/compare/master...file-utils.patch
If you find interesting this patch, then:
git pull https://github.com/jimenezrick/unix.git file-utils
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | -------------- |
| Version | 7.6.3 |
| Type | Task |
| TypeOfFailure | OtherFailure |
| Priority | normal |
| Resolution | Unresolved |
| Component | libraries/unix |
| Test case | |
| Differential revisions | |
| BlockedBy | |
| Related | |
| Blocking | |
| CC | |
| Operating system | |
| Architecture | |
</details>
<!-- {"blocked_by":[],"summary":"Pull request for inclusion in `unix' module of fsync(2), fdatasync(2), posix_fadvise(2) and posix_fallocate(2)","status":"New","operating_system":"","component":"libraries/unix","related":[],"milestone":"7.8.1","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"7.6.3","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"Task","description":"Discussion in the mailing list (I fixed both commented silly issues):\r\nhttp://www.haskell.org/pipermail/libraries/2013-December/021756.html\r\n\r\nPlease review this pull request:\r\nhttps://github.com/jimenezrick/unix/compare/master...file-utils.patch\r\n\r\nIf you find interesting this patch, then:\r\ngit pull https://github.com/jimenezrick/unix.git file-utils","type_of_failure":"OtherFailure","blocking":[]} -->7.10.1https://gitlab.haskell.org/ghc/ghc/-/issues/8433forkProcess masks async exceptions inside the child process2019-07-07T18:45:05ZjoeyhforkProcess masks async exceptions inside the child processFrankly, I'm not sure if this is a bug, but the forkProcess documentation says nothing about it. This can lead to problems when writing a multi-threaded daemon that expects async exceptions to work as they usually would.
FWIW, I have lo...Frankly, I'm not sure if this is a bug, but the forkProcess documentation says nothing about it. This can lead to problems when writing a multi-threaded daemon that expects async exceptions to work as they usually would.
FWIW, I have looked at several of the libraries on hackage that handle daemonization, and none of them seem to deal with this by explicitly unmasking exceptions when running the daemon IO action.
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | -------------- |
| Version | 7.6.3 |
| Type | Bug |
| TypeOfFailure | OtherFailure |
| Priority | normal |
| Resolution | Unresolved |
| Component | libraries/unix |
| Test case | |
| Differential revisions | |
| BlockedBy | |
| Related | |
| Blocking | |
| CC | |
| Operating system | |
| Architecture | |
</details>
<!-- {"blocked_by":[],"summary":"forkProcess masks async exceptions inside the child process","status":"New","operating_system":"","component":"libraries/unix","related":[],"milestone":"","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"7.6.3","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"Bug","description":"Frankly, I'm not sure if this is a bug, but the forkProcess documentation says nothing about it. This can lead to problems when writing a multi-threaded daemon that expects async exceptions to work as they usually would.\r\n\r\nFWIW, I have looked at several of the libraries on hackage that handle daemonization, and none of them seem to deal with this by explicitly unmasking exceptions when running the daemon IO action.","type_of_failure":"OtherFailure","blocking":[]} -->7.8.1https://gitlab.haskell.org/ghc/ghc/-/issues/8350shm_open and shm_unlink not detected on openSUSE Linux2019-07-07T18:45:26ZPeter Trommlerptrommler@acm.orgshm_open and shm_unlink not detected on openSUSE LinuxThe test in libraries/unix/configure fails to detect shm_\* functions on openSUSE. The -lrt flag is passed as part of CFLAGS rather than in LIBS and so it appears before the object file referencing the shm_\* function.
Note: The openSUS...The test in libraries/unix/configure fails to detect shm_\* functions on openSUSE. The -lrt flag is passed as part of CFLAGS rather than in LIBS and so it appears before the object file referencing the shm_\* function.
Note: The openSUSE linker sets --as-needed by default and hence the order of linker options does matter.
The attached patch fixes the issue.
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | -------------- |
| Version | 7.7 |
| Type | Bug |
| TypeOfFailure | OtherFailure |
| Priority | normal |
| Resolution | Unresolved |
| Component | libraries/unix |
| Test case | |
| Differential revisions | |
| BlockedBy | |
| Related | |
| Blocking | |
| CC | |
| Operating system | |
| Architecture | |
</details>
<!-- {"blocked_by":[],"summary":"shm_open and shm_unlink not detected on openSUSE Linux","status":"New","operating_system":"","component":"libraries/unix","related":[],"milestone":"7.8.1","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"7.7","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"Bug","description":"The test in libraries/unix/configure fails to detect shm_* functions on openSUSE. The -lrt flag is passed as part of CFLAGS rather than in LIBS and so it appears before the object file referencing the shm_* function.\r\n\r\nNote: The openSUSE linker sets --as-needed by default and hence the order of linker options does matter.\r\n\r\nThe attached patch fixes the issue.","type_of_failure":"OtherFailure","blocking":[]} -->7.8.1https://gitlab.haskell.org/ghc/ghc/-/issues/8293user001 spuriously fails if getGroupEntryForID correctly fails2019-07-07T18:45:41ZEdward Z. Yanguser001 spuriously fails if getGroupEntryForID correctly failsIn some cases, a user's current group ID can be a number for a non-existent group. While this usually indicates the system is misconfigured in some way, it can also occur inside chroots or other environments where the information in /etc...In some cases, a user's current group ID can be a number for a non-existent group. While this usually indicates the system is misconfigured in some way, it can also occur inside chroots or other environments where the information in /etc/groups is not to be considered reliable. Unfortunately, the user001 has no way of telling that the failure is proper, and fails the test anyway. We ought to do something more robust.
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | -------------- |
| Version | 7.7 |
| Type | Bug |
| TypeOfFailure | OtherFailure |
| Priority | lowest |
| Resolution | Unresolved |
| Component | libraries/unix |
| Test case | |
| Differential revisions | |
| BlockedBy | |
| Related | |
| Blocking | |
| CC | |
| Operating system | |
| Architecture | |
</details>
<!-- {"blocked_by":[],"summary":"user001 spuriously fails if getGroupEntryForID correctly fails","status":"New","operating_system":"","component":"libraries/unix","related":[],"milestone":"","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"7.7","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"Bug","description":"In some cases, a user's current group ID can be a number for a non-existent group. While this usually indicates the system is misconfigured in some way, it can also occur inside chroots or other environments where the information in /etc/groups is not to be considered reliable. Unfortunately, the user001 has no way of telling that the failure is proper, and fails the test anyway. We ought to do something more robust.","type_of_failure":"OtherFailure","blocking":[]} -->Edward KmettEdward Kmetthttps://gitlab.haskell.org/ghc/ghc/-/issues/8286fdToHandle docs are wrong about non-blocking mode2019-07-07T18:45:43ZduncanfdToHandle docs are wrong about non-blocking modeThe docs for System.Posix.IO.fdToHandle state:
```
fdToHandle :: Fd -> IO HandleSource
Converts an Fd into a Handle that can be used with the standard Haskell IO
library (see System.IO).
GHC only: this function has the side effect of ...The docs for System.Posix.IO.fdToHandle state:
```
fdToHandle :: Fd -> IO HandleSource
Converts an Fd into a Handle that can be used with the standard Haskell IO
library (see System.IO).
GHC only: this function has the side effect of putting the Fd into
non-blocking mode (O_NONBLOCK) due to the way the standard IO library
implements multithreaded I/O.
```
The final paragraph is wrong. The code no longer does this. System.Posix.IO.fdToHandle ends up calling GHC.IO.Handle.FD.fdToHandle which has this comment:
```
fdToHandle :: Posix.FD -> IO Handle
fdToHandle fdint = do
iomode <- Posix.fdGetMode fdint
(fd,fd_type) <- FD.mkFD fdint iomode Nothing
False{-is_socket-}
-- NB. the is_socket flag is False, meaning that:
-- on Windows we're guessing this is not a socket (XXX)
False{-is_nonblock-}
-- file descriptors that we get from external sources are
-- not put into non-blocking mode, because that would affect
-- other users of the file descriptor
```
So clearly, it is now deliberately not putting it into non-blocking mode.
This can trip people up who expect that it does put it into non-blocking mode, when in fact they now have to do that manually.
Fix is trivial: delete that paragraph from the docs for that function.
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | -------------- |
| Version | 7.6.3 |
| Type | Bug |
| TypeOfFailure | OtherFailure |
| Priority | normal |
| Resolution | Unresolved |
| Component | libraries/unix |
| Test case | |
| Differential revisions | |
| BlockedBy | |
| Related | |
| Blocking | |
| CC | |
| Operating system | |
| Architecture | |
</details>
<!-- {"blocked_by":[],"summary":"fdToHandle docs are wrong about non-blocking mode","status":"New","operating_system":"","component":"libraries/unix","related":[],"milestone":"","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"7.6.3","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"Bug","description":"The docs for System.Posix.IO.fdToHandle state:\r\n\r\n{{{\r\nfdToHandle :: Fd -> IO HandleSource\r\n\r\nConverts an Fd into a Handle that can be used with the standard Haskell IO\r\nlibrary (see System.IO).\r\n\r\nGHC only: this function has the side effect of putting the Fd into\r\nnon-blocking mode (O_NONBLOCK) due to the way the standard IO library\r\nimplements multithreaded I/O. \r\n}}}\r\n\r\nThe final paragraph is wrong. The code no longer does this. System.Posix.IO.fdToHandle ends up calling GHC.IO.Handle.FD.fdToHandle which has this comment:\r\n{{{\r\nfdToHandle :: Posix.FD -> IO Handle\r\nfdToHandle fdint = do\r\n iomode <- Posix.fdGetMode fdint\r\n (fd,fd_type) <- FD.mkFD fdint iomode Nothing\r\n False{-is_socket-}\r\n -- NB. the is_socket flag is False, meaning that:\r\n -- on Windows we're guessing this is not a socket (XXX)\r\n False{-is_nonblock-}\r\n -- file descriptors that we get from external sources are\r\n -- not put into non-blocking mode, because that would affect\r\n -- other users of the file descriptor\r\n}}}\r\n\r\nSo clearly, it is now deliberately not putting it into non-blocking mode.\r\n\r\nThis can trip people up who expect that it does put it into non-blocking mode, when in fact they now have to do that manually.\r\n\r\nFix is trivial: delete that paragraph from the docs for that function.","type_of_failure":"OtherFailure","blocking":[]} -->https://gitlab.haskell.org/ghc/ghc/-/issues/8223System.Posix.User fails to build on systems without get{gr,pw}nam_r2019-07-07T18:45:58ZrwbartonSystem.Posix.User fails to build on systems without get{gr,pw}nam_rI'm trying to build GHC for Android (using https://github.com/neurocyte/ghc-android) and according to `include/HsUnixConfig.h` Android doesn't have any of the `_r` functions in the `get{gr,pw}*` family.
In `System/Posix/User.hsc` the im...I'm trying to build GHC for Android (using https://github.com/neurocyte/ghc-android) and according to `include/HsUnixConfig.h` Android doesn't have any of the `_r` functions in the `get{gr,pw}*` family.
In `System/Posix/User.hsc` the imports of `Control.Monad` and `System.IO.Error` are conditional on `defined(HAVE_GETGRNAM_R) || defined(HAVE_GETPWNAM_R)`, but the use site of those modules (`doubleAllocWhileERANGE`) was moved outside of any `#if`s by http://git.haskell.org/?p=packages/unix.git;a=commit;h=ef683c6ba703.
I would suggest just removing the conditionals around the import of those two modules, since `doubleAllocWhileERANGE` is by now used by four other functions. Otherwise, need to bracket the definition of `doubleAllocWhileERANGE` with the same conditional as the one around those imports, and should update the conditionals to reflect all four cases in which `doubleAllocWhileERANGE` is used.
(BTW, does Android count as "Operating System: Linux"? It is based on the Linux kernel, but with a rather peculiar user-space.)
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | -------------- |
| Version | 7.7 |
| Type | Bug |
| TypeOfFailure | OtherFailure |
| Priority | normal |
| Resolution | Unresolved |
| Component | libraries/unix |
| Test case | |
| Differential revisions | |
| BlockedBy | |
| Related | |
| Blocking | |
| CC | |
| Operating system | |
| Architecture | |
</details>
<!-- {"blocked_by":[],"summary":"System.Posix.User fails to build on systems without get{gr,pw}nam_r","status":"New","operating_system":"","component":"libraries/unix","related":[],"milestone":"","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"7.7","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"Bug","description":"I'm trying to build GHC for Android (using https://github.com/neurocyte/ghc-android) and according to `include/HsUnixConfig.h` Android doesn't have any of the `_r` functions in the `get{gr,pw}*` family.\r\n\r\nIn `System/Posix/User.hsc` the imports of `Control.Monad` and `System.IO.Error` are conditional on `defined(HAVE_GETGRNAM_R) || defined(HAVE_GETPWNAM_R)`, but the use site of those modules (`doubleAllocWhileERANGE`) was moved outside of any `#if`s by http://git.haskell.org/?p=packages/unix.git;a=commit;h=ef683c6ba703.\r\n\r\nI would suggest just removing the conditionals around the import of those two modules, since `doubleAllocWhileERANGE` is by now used by four other functions. Otherwise, need to bracket the definition of `doubleAllocWhileERANGE` with the same conditional as the one around those imports, and should update the conditionals to reflect all four cases in which `doubleAllocWhileERANGE` is used.\r\n\r\n(BTW, does Android count as \"Operating System: Linux\"? It is based on the Linux kernel, but with a rather peculiar user-space.)","type_of_failure":"OtherFailure","blocking":[]} -->https://gitlab.haskell.org/ghc/ghc/-/issues/8108getGroupEntryForID segfaults in multi-threaded applications2019-07-07T18:46:27ZrednebgetGroupEntryForID segfaults in multi-threaded applicationsThe following program
```haskell
import Control.Monad
import Control.Concurrent
import System.Posix.User
main = do
void $ forkIO $ forever $ getGroupEntryForID 0
forever $ getGroupEntryForID 0
```
segfaults when executed after...The following program
```haskell
import Control.Monad
import Control.Concurrent
import System.Posix.User
main = do
void $ forkIO $ forever $ getGroupEntryForID 0
forever $ getGroupEntryForID 0
```
segfaults when executed after less than a second. I've confirmed this with HP-2013.2.0.0/GHC-7.63/unix-2.6.0.1 in many different linuxes as well as Mac OS X 10.8. After some digging I found the reason for this failure. The underlying posix function used by getGroupEntryForID is:
```c
int getgrgid_r(gid_t gid, struct group *grp, char *buf, size_t buflen, struct group **result);
```
getgrgid_r returns its result with its last argument which is a pointer to a struct. The struct has to be allocated by the caller as usual. The problem is that the struct contains several strings. This is what the char \*buf argument is for; the caller is supposed to allocate a large enough buffer to be used by getgrgid_r to store those strings. Then the caller has to read the struct \*before\* the auxiliary string buffer is deallocated. What complicates things even more is that we don't know in advance the right size for that buffer; we have to pick an arbitrary size and then keep doubling it while getgrgid_r returns ERANGE. The current implementation of getGroupEntryForID uses allocaBytes to allocate that buffer but then it does not unpack the struct inside the allocaBytes block.
The posix functions getgrnam_r, getpwuid_r and getpwnam_r (used by getGroupEntryForName, getUserEntryForID and getUserEntryForName respectively) operate in the same fashion and are susceptible to the same bug.
I am really surprised that people haven't been hitting that issue earlier.
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | -------------- |
| Version | 7.6.3 |
| Type | Bug |
| TypeOfFailure | OtherFailure |
| Priority | normal |
| Resolution | Unresolved |
| Component | libraries/unix |
| Test case | |
| Differential revisions | |
| BlockedBy | |
| Related | |
| Blocking | |
| CC | |
| Operating system | |
| Architecture | |
</details>
<!-- {"blocked_by":[],"summary":"getGroupEntryForID in multi-threaded applications","status":"New","operating_system":"","component":"libraries/unix","related":[],"milestone":"","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"7.6.3","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"Bug","description":"The following program\r\n\r\n{{{\r\n#!haskell\r\nimport Control.Monad\r\nimport Control.Concurrent\r\nimport System.Posix.User\r\n\r\nmain = do\r\n void $ forkIO $ forever $ getGroupEntryForID 0\r\n forever $ getGroupEntryForID 0\r\n}}}\r\n\r\nsegfaults when executed after less than a second. I've confirmed this with HP-2013.2.0.0/GHC-7.63/unix-2.6.0.1 in many different linuxes as well as Mac OS X 10.8. After some digging I found the reason for this failure. The underlying posix function used by getGroupEntryForID is:\r\n\r\n{{{\r\n#!c\r\nint getgrgid_r(gid_t gid, struct group *grp, char *buf, size_t buflen, struct group **result);\r\n}}}\r\n\r\ngetgrgid_r returns its result with its last argument which is a pointer to a struct. The struct has to be allocated by the caller as usual. The problem is that the struct contains several strings. This is what the char *buf argument is for; the caller is supposed to allocate a large enough buffer to be used by getgrgid_r to store those strings. Then the caller has to read the struct *before* the auxiliary string buffer is deallocated. What complicates things even more is that we don't know in advance the right size for that buffer; we have to pick an arbitrary size and then keep doubling it while getgrgid_r returns ERANGE. The current implementation of getGroupEntryForID uses allocaBytes to allocate that buffer but then it does not unpack the struct inside the allocaBytes block.\r\n\r\nThe posix functions getgrnam_r, getpwuid_r and getpwnam_r (used by getGroupEntryForName, getUserEntryForID and getUserEntryForName respectively) operate in the same fashion and are susceptible to the same bug.\r\n\r\nI am really surprised that people haven't been hitting that issue earlier.","type_of_failure":"OtherFailure","blocking":[]} -->https://gitlab.haskell.org/ghc/ghc/-/issues/7921DSO linking bug in unix package2019-07-07T18:47:26ZSimon Hengelsol@typeful.netDSO linking bug in unix package`unix` depends on `libpthread`, but it's not listed under `extra-libraries` in the cabal file. For that reason some programs fail to build on Ubuntu 13.04.
Steps to reproduce:
```
-- Main.hs
import System.Posix.Semaphore
main :: IO ()...`unix` depends on `libpthread`, but it's not listed under `extra-libraries` in the cabal file. For that reason some programs fail to build on Ubuntu 13.04.
Steps to reproduce:
```
-- Main.hs
import System.Posix.Semaphore
main :: IO ()
main = do
semUnlink "foo"
```
```
$ ghc --make Main.hs
```
Expected result: Program is compiled and linked.
Actual result: Liking fails with
```
/usr/bin/ld: /home/foo/.install/haskell/ghc-7.6.2/lib/ghc-7.6.2/unix-2.6.0.1/libHSunix-2.6.0.1.a(Semaphore__5.o): undefined reference to symbol 'sem_unlink@@GLIBC_2.2.5'
/usr/bin/ld: note: 'sem_unlink@@GLIBC_2.2.5' is defined in DSO /lib/x86_64-linux-gnu/libpthread.so.0 so try adding it to the linker command line
/lib/x86_64-linux-gnu/libpthread.so.0: could not read symbols: Invalid operation
collect2: error: ld returned 1 exit status
```
This is related to https://fedoraproject.org/wiki/UnderstandingDSOLinkChange.
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | -------------- |
| Version | 7.6.3 |
| Type | Bug |
| TypeOfFailure | OtherFailure |
| Priority | normal |
| Resolution | Unresolved |
| Component | libraries/unix |
| Test case | |
| Differential revisions | |
| BlockedBy | |
| Related | |
| Blocking | |
| CC | |
| Operating system | |
| Architecture | |
</details>
<!-- {"blocked_by":[],"summary":"DSO linking bug in unix package","status":"New","operating_system":"","component":"libraries/unix","related":[],"milestone":"","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"7.6.3","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"Bug","description":"{{{unix}}} depends on {{{libpthread}}}, but it's not listed under {{{extra-libraries}}} in the cabal file. For that reason some programs fail to build on Ubuntu 13.04.\r\n\r\nSteps to reproduce:\r\n{{{\r\n-- Main.hs\r\nimport System.Posix.Semaphore\r\n\r\nmain :: IO ()\r\nmain = do\r\n semUnlink \"foo\"\r\n}}}\r\n{{{\r\n$ ghc --make Main.hs\r\n}}}\r\n\r\nExpected result: Program is compiled and linked.\r\n\r\nActual result: Liking fails with\r\n{{{\r\n/usr/bin/ld: /home/foo/.install/haskell/ghc-7.6.2/lib/ghc-7.6.2/unix-2.6.0.1/libHSunix-2.6.0.1.a(Semaphore__5.o): undefined reference to symbol 'sem_unlink@@GLIBC_2.2.5'\r\n/usr/bin/ld: note: 'sem_unlink@@GLIBC_2.2.5' is defined in DSO /lib/x86_64-linux-gnu/libpthread.so.0 so try adding it to the linker command line\r\n/lib/x86_64-linux-gnu/libpthread.so.0: could not read symbols: Invalid operation\r\ncollect2: error: ld returned 1 exit status\r\n}}}\r\n\r\nThis is related to https://fedoraproject.org/wiki/UnderstandingDSOLinkChange.","type_of_failure":"OtherFailure","blocking":[]} -->