GHC issueshttps://gitlab.haskell.org/ghc/ghc/-/issues2019-07-07T18:47:48Zhttps://gitlab.haskell.org/ghc/ghc/-/issues/7853UTF encodings do not detect overlong forms2019-07-07T18:47:48ZbatterseapowerUTF encodings do not detect overlong formsOverlong UTF-{8,16} sequences can have security implications (http://www.cl.cam.ac.uk/\~mgk25/unicode.html). Decoders for these encodings should detect them and flag them as invalid characters. GHC's implementations of these decoders do ...Overlong UTF-{8,16} sequences can have security implications (http://www.cl.cam.ac.uk/\~mgk25/unicode.html). Decoders for these encodings should detect them and flag them as invalid characters. GHC's implementations of these decoders do not do so!
This problem has additional implications for GHC since as we are not rejecting overlong sequences, trying to roundtrip 0xC0 0xB1 through UTF-8//ROUNDTRIP results in 0x31 rather than the expected sequence. The roundtripping fails because the overlong sequence is not flagged up by the UTF-8 encoder and so the surrogate escape mechanism never gets a chance to work.
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | -------------- |
| Version | 7.6.3 |
| Type | Bug |
| TypeOfFailure | OtherFailure |
| Priority | normal |
| Resolution | Unresolved |
| Component | libraries/base |
| Test case | |
| Differential revisions | |
| BlockedBy | |
| Related | |
| Blocking | |
| CC | |
| Operating system | |
| Architecture | |
</details>
<!-- {"blocked_by":[],"summary":"UTF encodings do not detect overlong forms","status":"New","operating_system":"","component":"libraries/base","related":[],"milestone":"","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"7.6.3","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"Bug","description":"Overlong UTF-{8,16} sequences can have security implications (http://www.cl.cam.ac.uk/~mgk25/unicode.html). Decoders for these encodings should detect them and flag them as invalid characters. GHC's implementations of these decoders do not do so!\r\n\r\nThis problem has additional implications for GHC since as we are not rejecting overlong sequences, trying to roundtrip 0xC0 0xB1 through UTF-8//ROUNDTRIP results in 0x31 rather than the expected sequence. The roundtripping fails because the overlong sequence is not flagged up by the UTF-8 encoder and so the surrogate escape mechanism never gets a chance to work.","type_of_failure":"OtherFailure","blocking":[]} -->https://gitlab.haskell.org/ghc/ghc/-/issues/7839After forkIO'ing on Intel Mac, putStrLn (presumably) reports "hPutChar: faile...2019-07-07T18:47:52ZthorkilnaurAfter forkIO'ing on Intel Mac, putStrLn (presumably) reports "hPutChar: failed (Operation not supported)"Investigating #7715 on the tn23 builder, which is
```
$ uname -a
Darwin thorkil-naurs-intel-mac-mini.local 9.8.0 Darwin Kernel Version 9.8.0: Wed Jul 15 16:55:01 PDT 2009; root:xnu-1228.15.4~1/RELEASE_I386 i386
$
```
I ran into:
```
...Investigating #7715 on the tn23 builder, which is
```
$ uname -a
Darwin thorkil-naurs-intel-mac-mini.local 9.8.0 Darwin Kernel Version 9.8.0: Wed Jul 15 16:55:01 PDT 2009; root:xnu-1228.15.4~1/RELEASE_I386 i386
$
```
I ran into:
```
$ cat T7715O.hs
import Control.Monad
import Control.Concurrent
import System.IO
import System.Environment
main' c d2 = do
replicateM_ c $ forkIO $ do
putStrLn "Hello, world!"
threadDelay d2
mainArgsInterpret [cS,d2S] = main' (read cS) (read d2S)
main :: IO ()
main
= do
hSetBuffering stdout NoBuffering
hSetBuffering stderr NoBuffering
args <- getArgs
mainArgsInterpret args
$ /Users/thorkilnaur/tn/builders/GHCBuilder/tn23/builder/tempbuild/build/inplace/bin/ghc-stage2 --make T7715O.hs -threaded -debug -rtsopts
[1 of 1] Compiling Main ( T7715O.hs, T7715O.o )
Linking T7715O ...
$ ./T7715O 25 10000000
Hello, world!
Hello, world!
Hello, world!
Hello, world!
Hello, world!
Hello, world!
Hello, world!
Hello, world!
Hello, world!
Hello, world!
Hello, world!
Hello, world!
Hello, world!
Hello, world!
Hello, world!
Hello, world!
Hello, world!
Hello, world!
Hello, world!
Hello, world!
Hello, world!
Hello, world!
Hello, world!
HeT7715O: <stdout>: hPutChar: failed (Operation not supported)
T7715O: <stdout>: hPutChar: failed (Operation not supported)
$
```
This doesn't happen on
```
$ uname -a
Linux tn24 3.2.0-39-generic #62-Ubuntu SMP Wed Feb 27 22:05:17 UTC 2013 i686 i686 i386 GNU/Linux
$
```
Best regards
Thorkil
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | -------------- |
| Version | 7.7 |
| Type | Bug |
| TypeOfFailure | OtherFailure |
| Priority | normal |
| Resolution | Unresolved |
| Component | Runtime System |
| Test case | |
| Differential revisions | |
| BlockedBy | |
| Related | |
| Blocking | |
| CC | |
| Operating system | |
| Architecture | |
</details>
<!-- {"blocked_by":[],"summary":"After forkIO'ing on Intel Mac, putStrLn (presumably) reports \"hPutChar: failed (Operation not supported)\"","status":"New","operating_system":"","component":"Runtime System","related":[],"milestone":"","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"7.7","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"Bug","description":"Investigating #7715 on the tn23 builder, which is\r\n{{{\r\n$ uname -a\r\nDarwin thorkil-naurs-intel-mac-mini.local 9.8.0 Darwin Kernel Version 9.8.0: Wed Jul 15 16:55:01 PDT 2009; root:xnu-1228.15.4~1/RELEASE_I386 i386\r\n$ \r\n}}}\r\nI ran into:\r\n{{{\r\n$ cat T7715O.hs \r\nimport Control.Monad\r\nimport Control.Concurrent\r\nimport System.IO\r\nimport System.Environment\r\n\r\nmain' c d2 = do\r\n replicateM_ c $ forkIO $ do\r\n putStrLn \"Hello, world!\"\r\n threadDelay d2\r\n\r\nmainArgsInterpret [cS,d2S] = main' (read cS) (read d2S)\r\n\r\nmain :: IO ()\r\nmain\r\n = do\r\n hSetBuffering stdout NoBuffering\r\n hSetBuffering stderr NoBuffering\r\n args <- getArgs\r\n mainArgsInterpret args\r\n$ /Users/thorkilnaur/tn/builders/GHCBuilder/tn23/builder/tempbuild/build/inplace/bin/ghc-stage2 --make T7715O.hs -threaded -debug -rtsopts \r\n[1 of 1] Compiling Main ( T7715O.hs, T7715O.o )\r\nLinking T7715O ...\r\n$ ./T7715O 25 10000000 \r\nHello, world!\r\nHello, world!\r\nHello, world!\r\nHello, world!\r\nHello, world!\r\nHello, world!\r\nHello, world!\r\nHello, world!\r\nHello, world!\r\nHello, world!\r\nHello, world!\r\nHello, world!\r\nHello, world!\r\nHello, world!\r\nHello, world!\r\nHello, world!\r\nHello, world!\r\nHello, world!\r\nHello, world!\r\nHello, world!\r\nHello, world!\r\nHello, world!\r\nHello, world!\r\nHeT7715O: <stdout>: hPutChar: failed (Operation not supported)\r\nT7715O: <stdout>: hPutChar: failed (Operation not supported)\r\n$\r\n}}}\r\nThis doesn't happen on\r\n{{{\r\n$ uname -a\r\nLinux tn24 3.2.0-39-generic #62-Ubuntu SMP Wed Feb 27 22:05:17 UTC 2013 i686 i686 i386 GNU/Linux\r\n$ \r\n}}}\r\nBest regards\r\nThorkil\r\n","type_of_failure":"OtherFailure","blocking":[]} -->https://gitlab.haskell.org/ghc/ghc/-/issues/7815STM fails to validate read.2020-01-29T16:18:56ZRyan YatesSTM fails to validate read.This issue was brought up by napping in `#haskell` with this paste:
[http://hpaste.org/85134](http://hpaste.org/85134) (the first paste in particular)
The code is:
```
import Control.Concurrent.STM
import Control.Concurrent
import Con...This issue was brought up by napping in `#haskell` with this paste:
[http://hpaste.org/85134](http://hpaste.org/85134) (the first paste in particular)
The code is:
```
import Control.Concurrent.STM
import Control.Concurrent
import Control.Monad
main = do
dog <- newTVarIO False
cat <- newTVarIO False
let unset = do
d <- readTVar dog
c <- readTVar cat
if (d || c) then retry else return ()
setDog = unset >> writeTVar dog True
setCat = unset >> writeTVar cat True
oops = do
d <- readTVar dog
c <- readTVar cat
guard (d && c)
reset = do
writeTVar dog False
writeTVar cat False
reset' = do
d <- readTVar dog
c <- readTVar cat
guard (d || c)
reset
forkIO (atomically oops >> putStrLn "Oh Noes!")
forever (do
forkIO (atomically setDog)
forkIO (atomically setCat)
atomically reset'
atomically reset')
```
When run it produces:
```
$ ghc --make test.hs -threaded -rtsopts
$ ./test +RTS -N2
Oh Noes!
test: thread blocked indefinitely in an STM transaction
```
The second message is just a consequence of entering an unexpected state. The first message indicates that both the transactions `cat` and `dog` committed at the same time.
It does this for HEAD and 7.6.
I've sketched out an interleaving that leads to this. TRec entries
are in the first and third column and TVar's are in the second column. Each entry has a TVar name and the expected value followed
by the new value and then a number of updates if it has been read. TVars list their value and their number of updates.
```
A TRec TVar B TRec
-- Transactions start
cat F F cat F 0 cat F F -- Initial reads.
dog F F dog F 0 dog F F
cat F T dog F T -- Local writes in TRec's
-- Validation:
cat F F 0 -- B reads num_updates from cat (with
^ -- consistency check with value)
cat F T cat A 0 | -- A acquires lock for cat (atomic cas)
dog F F 0 ^ | -- A reads num_updates from dog (with
^ | | -- consistency check with value)
| dog B 0 dog F T | -- B acquires lock for dog (atomic cas)
| | ^ |
| | | |
Success 0 | 0 | -- read check for A
Success 0 0 -- read check for B
cat A 1 -- Increment version
cat T 1 -- Unlock with new value
dog B 1 -- Increment version
dog B T -- Unlock with new value
```
What is clear here is that the version number is not enough to check
in `check_read_only` because there is a gap between locking and
incrementing the version. We need to know atomically that the TVar is not locked and it's version number is the same.
I need to read through the right parts of Keir Fraser's thesis carefully, but it seems like the read phase here is only helpful in preventing a commit that writes back the exact value we have already seen while we are in the middle of committing.
The code for `check_read_only` is here:
```c
static StgBool check_read_only(StgTRecHeader *trec STG_UNUSED) {
StgBool result = TRUE;
ASSERT (config_use_read_phase);
IF_STM_FG_LOCKS({
FOR_EACH_ENTRY(trec, e, {
StgTVar *s;
s = e -> tvar;
if (entry_is_read_only(e)) {
TRACE("%p : check_read_only for TVar %p, saw %ld", trec, s, e -> num_updates);
if (s -> num_updates != e -> num_updates) {
// ||s -> current_value != e -> expected_value) {
TRACE("%p : mismatch", trec);
result = FALSE;
BREAK_FOR_EACH;
}
}
});
});
return result;
}
```
If I restore the commented out line (which appears commented out in the first commit of this code that I can find) I can't reproduce the issue, but I think there is still a problem due to the ordering of
those checks: we could observe the version as the same, while it
is locked, have the TVar unlock, then observe the value the same.
Switching the order we can only observe the TVar unlocked if the
update has been incremented (as long as we are on an architecture
that ensures this such as x86).
Does this seem right? One issue is that given the interleaving that above with this added check *both* transactions could fail to commit. I think the algorithms from Fraser avoid this, but I think it always involves invalidating another transaction (i.e. killing off any other transactions observed to be in the read check phase with an overlapping TVar in a way that results in only one winner (see page 21 section 4.4 in *Concurrent Programming Without Locks*)).
As a side note, the issue can be avoided by ensuring that the reads become writes and avoiding the read only check. But you can only
become a write if the values do not have matching pointers, switching to Ints instead of Bools gets you there.
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | -------------- |
| Version | 7.7 |
| Type | Bug |
| TypeOfFailure | OtherFailure |
| Priority | normal |
| Resolution | Unresolved |
| Component | Runtime System |
| Test case | |
| Differential revisions | |
| BlockedBy | |
| Related | |
| Blocking | |
| CC | |
| Operating system | |
| Architecture | |
</details>
<!-- {"blocked_by":[],"summary":"STM fails to validate read.","status":"New","operating_system":"","component":"Runtime System","related":[],"milestone":"","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"7.7","keywords":["STM"],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"Bug","description":"This issue was brought up by napping in {{{#haskell}}} with this paste:\r\n\r\n[http://hpaste.org/85134] (the first paste in particular)\r\n\r\nThe code is:\r\n\r\n{{{\r\nimport Control.Concurrent.STM\r\nimport Control.Concurrent\r\nimport Control.Monad\r\n\r\nmain = do\r\n dog <- newTVarIO False\r\n cat <- newTVarIO False\r\n let unset = do\r\n d <- readTVar dog\r\n c <- readTVar cat\r\n if (d || c) then retry else return ()\r\n setDog = unset >> writeTVar dog True\r\n setCat = unset >> writeTVar cat True\r\n oops = do\r\n d <- readTVar dog\r\n c <- readTVar cat\r\n guard (d && c)\r\n reset = do\r\n writeTVar dog False\r\n writeTVar cat False\r\n reset' = do\r\n d <- readTVar dog\r\n c <- readTVar cat\r\n guard (d || c)\r\n reset\r\n\r\n forkIO (atomically oops >> putStrLn \"Oh Noes!\")\r\n forever (do\r\n forkIO (atomically setDog)\r\n forkIO (atomically setCat)\r\n atomically reset'\r\n atomically reset')\r\n}}}\r\n\r\nWhen run it produces:\r\n\r\n{{{\r\n$ ghc --make test.hs -threaded -rtsopts\r\n$ ./test +RTS -N2\r\nOh Noes!\r\ntest: thread blocked indefinitely in an STM transaction\r\n}}}\r\n\r\nThe second message is just a consequence of entering an unexpected state. The first message indicates that both the transactions {{{cat}}} and {{{dog}}} committed at the same time.\r\n\r\nIt does this for HEAD and 7.6.\r\n\r\nI've sketched out an interleaving that leads to this. TRec entries\r\nare in the first and third column and TVar's are in the second column. Each entry has a TVar name and the expected value followed\r\nby the new value and then a number of updates if it has been read. TVars list their value and their number of updates.\r\n\r\n{{{\r\n A TRec TVar B TRec\r\n -- Transactions start\r\ncat F F cat F 0 cat F F -- Initial reads.\r\ndog F F dog F 0 dog F F \r\n\r\ncat F T dog F T -- Local writes in TRec's\r\n \r\n -- Validation:\r\n\r\n cat F F 0 -- B reads num_updates from cat (with\r\n ^ -- consistency check with value)\r\ncat F T cat A 0 | -- A acquires lock for cat (atomic cas)\r\ndog F F 0 ^ | -- A reads num_updates from dog (with\r\n ^ | | -- consistency check with value)\r\n | dog B 0 dog F T | -- B acquires lock for dog (atomic cas)\r\n | | ^ | \r\n | | | |\r\nSuccess 0 | 0 | -- read check for A\r\nSuccess 0 0 -- read check for B\r\n\r\n cat A 1 -- Increment version\r\n cat T 1 -- Unlock with new value\r\n dog B 1 -- Increment version\r\n dog B T -- Unlock with new value\r\n}}}\r\n\r\nWhat is clear here is that the version number is not enough to check\r\nin {{{check_read_only}}} because there is a gap between locking and \r\nincrementing the version. We need to know atomically that the TVar is not locked and it's version number is the same.\r\n\r\nI need to read through the right parts of Keir Fraser's thesis carefully, but it seems like the read phase here is only helpful in preventing a commit that writes back the exact value we have already seen while we are in the middle of committing. \r\n\r\nThe code for {{{check_read_only}}} is here:\r\n\r\n{{{\r\n#!c\r\nstatic StgBool check_read_only(StgTRecHeader *trec STG_UNUSED) {\r\n StgBool result = TRUE;\r\n\r\n ASSERT (config_use_read_phase);\r\n IF_STM_FG_LOCKS({\r\n FOR_EACH_ENTRY(trec, e, {\r\n StgTVar *s;\r\n s = e -> tvar;\r\n if (entry_is_read_only(e)) {\r\n TRACE(\"%p : check_read_only for TVar %p, saw %ld\", trec, s, e -> num_updates);\r\n if (s -> num_updates != e -> num_updates) {\r\n // ||s -> current_value != e -> expected_value) {\r\n TRACE(\"%p : mismatch\", trec);\r\n result = FALSE;\r\n BREAK_FOR_EACH;\r\n }\r\n }\r\n });\r\n });\r\n\r\n return result;\r\n}\r\n}}}\r\n\r\nIf I restore the commented out line (which appears commented out in the first commit of this code that I can find) I can't reproduce the issue, but I think there is still a problem due to the ordering of\r\nthose checks: we could observe the version as the same, while it \r\nis locked, have the TVar unlock, then observe the value the same. \r\n\r\nSwitching the order we can only observe the TVar unlocked if the\r\nupdate has been incremented (as long as we are on an architecture\r\nthat ensures this such as x86).\r\n\r\nDoes this seem right? One issue is that given the interleaving that above with this added check ''both'' transactions could fail to commit. I think the algorithms from Fraser avoid this, but I think it always involves invalidating another transaction (i.e. killing off any other transactions observed to be in the read check phase with an overlapping TVar in a way that results in only one winner (see page 21 section 4.4 in ''Concurrent Programming Without Locks'')).\r\n\r\nAs a side note, the issue can be avoided by ensuring that the reads become writes and avoiding the read only check. But you can only \r\nbecome a write if the values do not have matching pointers, switching to Ints instead of Bools gets you there.","type_of_failure":"OtherFailure","blocking":[]} -->7.8.1Ian Lynagh <igloo@earth.li>Ian Lynagh <igloo@earth.li>https://gitlab.haskell.org/ghc/ghc/-/issues/7788Recursive type family causes <<loop>>2019-07-07T18:48:09ZshachafRecursive type family causes <<loop>>This file:
```
{-# LANGUAGE TypeFamilies #-}
{-# LANGUAGE UndecidableInstances #-}
data Proxy a = Proxy
foo :: Proxy (F (Fix Id)) -> ()
foo = undefined
newtype Fix a = Fix (a (Fix a))
newtype Id a = Id a
type family F a
type instanc...This file:
```
{-# LANGUAGE TypeFamilies #-}
{-# LANGUAGE UndecidableInstances #-}
data Proxy a = Proxy
foo :: Proxy (F (Fix Id)) -> ()
foo = undefined
newtype Fix a = Fix (a (Fix a))
newtype Id a = Id a
type family F a
type instance F (Fix a) = F (a (Fix a))
type instance F (Id a) = F a
main :: IO ()
main = print $ foo Proxy
```
Dies with `<<loop>>`. The type family is recursive, of course:
```
*Main> :kind! F (Fix Id)
F (Fix Id) :: *^CInterrupted.
```
But `<<loop>>` is still not the behavior I'd expect. The actual value is just `undefined`.
In the file that this example came up, the situation was even worse -- there was a situation where
```
moldMapOf l f = runAccessor . l (Accessor . f)
main = print $ (flip appEndo [] . moldMapOf (ix 3) (Endo . (:)) $ testVal :: [Int]) -- <<loop>>
main = print $ (flip appEndo [] . runAccessor . (ix 3) (Accessor . Endo . (:)) $ testVal :: [Int]) -- undefined
```
I.e. substitution can turn one program (which happens to be ⊥ here, admittedly, but that's not fundamental) into another (`<<loop>>`). This makes it very tricky to track down the recursive type family. If necessary I can hunt down a working test case and post it here -- it's a bit tricky to get working, though.
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | ------------ |
| Version | 7.6.2 |
| Type | Bug |
| TypeOfFailure | OtherFailure |
| Priority | normal |
| Resolution | Unresolved |
| Component | Compiler |
| Test case | |
| Differential revisions | |
| BlockedBy | |
| Related | |
| Blocking | |
| CC | |
| Operating system | |
| Architecture | |
</details>
<!-- {"blocked_by":[],"summary":"Recursive type family causes <<loop>>","status":"New","operating_system":"","component":"Compiler","related":[],"milestone":"","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"7.6.2","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"Bug","description":"This file:\r\n\r\n{{{\r\n{-# LANGUAGE TypeFamilies #-}\r\n{-# LANGUAGE UndecidableInstances #-}\r\n\r\ndata Proxy a = Proxy\r\n\r\nfoo :: Proxy (F (Fix Id)) -> ()\r\nfoo = undefined\r\n\r\nnewtype Fix a = Fix (a (Fix a))\r\nnewtype Id a = Id a\r\n\r\ntype family F a\r\ntype instance F (Fix a) = F (a (Fix a))\r\ntype instance F (Id a) = F a\r\n\r\nmain :: IO ()\r\nmain = print $ foo Proxy\r\n}}}\r\n\r\nDies with `<<loop>>`. The type family is recursive, of course:\r\n\r\n{{{\r\n*Main> :kind! F (Fix Id)\r\nF (Fix Id) :: *^CInterrupted.\r\n}}}\r\n\r\nBut `<<loop>>` is still not the behavior I'd expect. The actual value is just `undefined`.\r\n\r\nIn the file that this example came up, the situation was even worse -- there was a situation where\r\n\r\n{{{\r\nmoldMapOf l f = runAccessor . l (Accessor . f)\r\nmain = print $ (flip appEndo [] . moldMapOf (ix 3) (Endo . (:)) $ testVal :: [Int]) -- <<loop>>\r\nmain = print $ (flip appEndo [] . runAccessor . (ix 3) (Accessor . Endo . (:)) $ testVal :: [Int]) -- undefined\r\n}}}\r\n\r\nI.e. substitution can turn one program (which happens to be ⊥ here, admittedly, but that's not fundamental) into another (`<<loop>>`). This makes it very tricky to track down the recursive type family. If necessary I can hunt down a working test case and post it here -- it's a bit tricky to get working, though.","type_of_failure":"OtherFailure","blocking":[]} -->8.0.1Richard Eisenbergrae@richarde.devRichard Eisenbergrae@richarde.devhttps://gitlab.haskell.org/ghc/ghc/-/issues/7787modifyMVar does not restore value if callback returns error value2019-07-07T18:48:09ZjoeyadamsmodifyMVar does not restore value if callback returns error value`modifyMVar` is currently implemented as follows:
```
modifyMVar :: MVar a -> (a -> IO (a,b)) -> IO b
modifyMVar m io =
mask $ \restore -> do
a <- takeMVar m
(a',b) <- restore (io a) `onException` putMVar m a
putMVar ...`modifyMVar` is currently implemented as follows:
```
modifyMVar :: MVar a -> (a -> IO (a,b)) -> IO b
modifyMVar m io =
mask $ \restore -> do
a <- takeMVar m
(a',b) <- restore (io a) `onException` putMVar m a
putMVar m a'
return b
```
The problem is that it forces the `(a',b)` outside of the exception handler. If forcing this throws an exception, `putMVar` will not be called, and a subsequent `withMVar` or similar will hang. Example:
```
> import Control.Concurrent.MVar
> mv <- newMVar 'x'
> modifyMVar mv $ \_ -> return undefined
*** Exception: Prelude.undefined
> withMVar mv print
-- hang --
```
Perhaps we can fix it like this:
```
- (a',b) <- restore (io a) `onException` putMVar m a
+ (a',b) <- restore (io a >>= evaluate) `onException` putMVar m a
```
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | -------------- |
| Version | 7.7 |
| Type | Bug |
| TypeOfFailure | OtherFailure |
| Priority | normal |
| Resolution | Unresolved |
| Component | libraries/base |
| Test case | |
| Differential revisions | |
| BlockedBy | |
| Related | |
| Blocking | |
| CC | |
| Operating system | |
| Architecture | |
</details>
<!-- {"blocked_by":[],"summary":"modifyMVar does not restore value if callback returns error value","status":"New","operating_system":"","component":"libraries/base","related":[],"milestone":"","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"7.7","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"Bug","description":"`modifyMVar` is currently implemented as follows:\r\n\r\n{{{\r\nmodifyMVar :: MVar a -> (a -> IO (a,b)) -> IO b\r\nmodifyMVar m io =\r\n mask $ \\restore -> do\r\n a <- takeMVar m\r\n (a',b) <- restore (io a) `onException` putMVar m a\r\n putMVar m a'\r\n return b\r\n}}}\r\n\r\nThe problem is that it forces the `(a',b)` outside of the exception handler. If forcing this throws an exception, `putMVar` will not be called, and a subsequent `withMVar` or similar will hang. Example:\r\n\r\n{{{\r\n> import Control.Concurrent.MVar\r\n> mv <- newMVar 'x'\r\n> modifyMVar mv $ \\_ -> return undefined\r\n*** Exception: Prelude.undefined\r\n> withMVar mv print\r\n-- hang --\r\n}}}\r\n\r\nPerhaps we can fix it like this:\r\n\r\n{{{\r\n- (a',b) <- restore (io a) `onException` putMVar m a\r\n+ (a',b) <- restore (io a >>= evaluate) `onException` putMVar m a\r\n}}}","type_of_failure":"OtherFailure","blocking":[]} -->7.8.1Simon MarlowSimon Marlowhttps://gitlab.haskell.org/ghc/ghc/-/issues/7773Waiting on non-kqueue supported files on OS X2019-07-07T18:48:12ZAndreasVoellmyWaiting on non-kqueue supported files on OS XNeither the old IO manager nor the new "parallel" IO manager properly handle waiting on files on Mac OS X when kqueue does not support the device type. PHO reported this on ghc-devs: http://www.haskell.org/pipermail/ghc-devs/2013-March/0...Neither the old IO manager nor the new "parallel" IO manager properly handle waiting on files on Mac OS X when kqueue does not support the device type. PHO reported this on ghc-devs: http://www.haskell.org/pipermail/ghc-devs/2013-March/000798.html.
Here is the gist of it: the IO manager uses kqueue to wait on files on OS X. kqueue does not support all files. For example, on older versions of OS X (10.5.8) it cannot wait on tty devices and on even on 10.8.2 it cannot wait on /dev/random.
Both the old and parallel IO managers suffered from the problem, but the consequences were slightly different. With the old IO manager the situation was treated as the file being ready, which would just cause the waiting thread to run again. The parallel IO manager changed things slightly and now it just throws an exception and terminates the program. So the behavior when this happens in the parallel IO manager is not acceptable.
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | -------------- |
| Version | 7.7 |
| Type | Bug |
| TypeOfFailure | OtherFailure |
| Priority | normal |
| Resolution | Unresolved |
| Component | libraries/base |
| Test case | |
| Differential revisions | |
| BlockedBy | |
| Related | |
| Blocking | |
| CC | |
| Operating system | |
| Architecture | |
</details>
<!-- {"blocked_by":[],"summary":"Waiting on non-kqueue supported files on OS X","status":"New","operating_system":"","component":"libraries/base","related":[],"milestone":"","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"7.7","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"Bug","description":"Neither the old IO manager nor the new \"parallel\" IO manager properly handle waiting on files on Mac OS X when kqueue does not support the device type. PHO reported this on ghc-devs: http://www.haskell.org/pipermail/ghc-devs/2013-March/000798.html.\r\n\r\nHere is the gist of it: the IO manager uses kqueue to wait on files on OS X. kqueue does not support all files. For example, on older versions of OS X (10.5.8) it cannot wait on tty devices and on even on 10.8.2 it cannot wait on /dev/random. \r\n\r\nBoth the old and parallel IO managers suffered from the problem, but the consequences were slightly different. With the old IO manager the situation was treated as the file being ready, which would just cause the waiting thread to run again. The parallel IO manager changed things slightly and now it just throws an exception and terminates the program. So the behavior when this happens in the parallel IO manager is not acceptable.\r\n\r\n","type_of_failure":"OtherFailure","blocking":[]} -->7.8.1AndreasVoellmyAndreasVoellmyhttps://gitlab.haskell.org/ghc/ghc/-/issues/7716ZonedTime read instance failing to parse what show returns2019-07-07T18:48:26Zmercer92ZonedTime read instance failing to parse what show returnsTest case:
```
import Data.Time
main = do
time <- getZonedTime
let string = show time
print string
print $ (read string :: ZonedTime)
```
This gives me:
```
*Main> main
"2013-02-24 14:51:56.453125 Central European Standard Ti...Test case:
```
import Data.Time
main = do
time <- getZonedTime
let string = show time
print string
print $ (read string :: ZonedTime)
```
This gives me:
```
*Main> main
"2013-02-24 14:51:56.453125 Central European Standard Time"
*** Exception: Prelude.read: no parse
```
Reportedly this works with (some) other timezones, so be sure to also test it with mine (show time =\> "2013-02-24 14:51:56.453125 Central European Standard Time").
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | ----------------- |
| Version | 7.4.2 |
| Type | Bug |
| TypeOfFailure | OtherFailure |
| Priority | normal |
| Resolution | Unresolved |
| Component | libraries (other) |
| Test case | |
| Differential revisions | |
| BlockedBy | |
| Related | |
| Blocking | |
| CC | |
| Operating system | |
| Architecture | |
</details>
<!-- {"blocked_by":[],"summary":"Zonetime read instance failing to parse what show returns","status":"New","operating_system":"","component":"libraries (other)","related":[],"milestone":"","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"7.4.2","keywords":["ZoneTime","read","show"],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"Bug","description":"Test case:\r\n{{{\r\nimport Data.Time\r\n\r\nmain = do\r\n time <- getZonedTime\r\n let string = show time\r\n print string\r\n print $ (read string :: ZonedTime)\r\n}}}\r\n\r\nThis gives me:\r\n\r\n\r\n{{{\r\n*Main> main\r\n\"2013-02-24 14:51:56.453125 Central European Standard Time\"\r\n*** Exception: Prelude.read: no parse\r\n}}}\r\n\r\nReportedly this works with (some) other timezones, so be sure to also test it with mine (show time => \"2013-02-24 14:51:56.453125 Central European Standard Time\").","type_of_failure":"OtherFailure","blocking":[]} -->https://gitlab.haskell.org/ghc/ghc/-/issues/7646resource busy (file is locked) with multi-threaded file ops2019-07-07T18:48:51ZStefanWehrresource busy (file is locked) with multi-threaded file opsThe sample program attached creates 10 worker threads, each of which takes a different file name. Each worker thread then writes the file, reads the file, writes the file and so on. File operations use \*strict IO\*.
When compiled witho...The sample program attached creates 10 worker threads, each of which takes a different file name. Each worker thread then writes the file, reads the file, writes the file and so on. File operations use \*strict IO\*.
When compiled without `-threaded` everything is ok, that is, the program goes on forever without any error messages.
But with `-threaded`, the program quickly fails with `ERROR in worker 4: 4: openBinaryFile: resource busy (file is locked)`.
Tested under Mac OSX 10.8.2 and Linux.
Tested with both GHC 7.6.1 and 7.6.2.
I could reproduce the bug without +RTS -N -RTS and with this RTS option. A colleague of mine reports that it needs +RTS -N2 -RTS to reproduce the bug.
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | -------------- |
| Version | 7.6.1 |
| Type | Bug |
| TypeOfFailure | OtherFailure |
| Priority | normal |
| Resolution | Unresolved |
| Component | Runtime System |
| Test case | |
| Differential revisions | |
| BlockedBy | |
| Related | |
| Blocking | |
| CC | |
| Operating system | |
| Architecture | |
</details>
<!-- {"blocked_by":[],"summary":"resource busy (file is locked) with multi-threaded file ops","status":"New","operating_system":"","component":"Runtime System","related":[],"milestone":"","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"7.6.1","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"Bug","description":"The sample program attached creates 10 worker threads, each of which takes a different file name. Each worker thread then writes the file, reads the file, writes the file and so on. File operations use *strict IO*.\r\n\r\nWhen compiled without `-threaded` everything is ok, that is, the program goes on forever without any error messages.\r\n\r\nBut with `-threaded`, the program quickly fails with `ERROR in worker 4: 4: openBinaryFile: resource busy (file is locked)`.\r\n\r\nTested under Mac OSX 10.8.2 and Linux.\r\nTested with both GHC 7.6.1 and 7.6.2.\r\n\r\nI could reproduce the bug without +RTS -N -RTS and with this RTS option. A colleague of mine reports that it needs +RTS -N2 -RTS to reproduce the bug.","type_of_failure":"OtherFailure","blocking":[]} -->7.6.3Simon MarlowSimon Marlowhttps://gitlab.haskell.org/ghc/ghc/-/issues/7613readSigned consumes too much input2019-07-07T18:48:59ZliyangreadSigned consumes too much input```
> reads "0.1" :: [(Int, String)]
[]
```
I would have expected `[(0, ".1")]`. The Report specifies that `reads` for `Int` ought to essentially be `readSigned readDec`, and indeed `readDec` gives the expected result:
```
> readDec "0...```
> reads "0.1" :: [(Int, String)]
[]
```
I would have expected `[(0, ".1")]`. The Report specifies that `reads` for `Int` ought to essentially be `readSigned readDec`, and indeed `readDec` gives the expected result:
```
> readDec "0.1"
[(0,".1")]
```
I think the bug is due to the use of `lex` in `readSigned`, which consumes the entire "0.1" string, such that readDec no longer gives a clean parse.
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | -------------- |
| Version | 7.6.1 |
| Type | Bug |
| TypeOfFailure | OtherFailure |
| Priority | normal |
| Resolution | Unresolved |
| Component | libraries/base |
| Test case | |
| Differential revisions | |
| BlockedBy | |
| Related | |
| Blocking | |
| CC | |
| Operating system | |
| Architecture | |
</details>
<!-- {"blocked_by":[],"summary":"readSigned consumes too much input","status":"New","operating_system":"","component":"libraries/base","related":[],"milestone":"","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"7.6.1","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"Bug","description":"{{{\r\n> reads \"0.1\" :: [(Int, String)]\r\n[]\r\n}}}\r\n\r\nI would have expected {{{[(0, \".1\")]}}}. The Report specifies that {{{reads}}} for {{{Int}}} ought to essentially be {{{readSigned readDec}}}, and indeed {{{readDec}}} gives the expected result:\r\n{{{\r\n> readDec \"0.1\"\r\n[(0,\".1\")]\r\n}}}\r\n\r\nI think the bug is due to the use of {{{lex}}} in {{{readSigned}}}, which consumes the entire \"0.1\" string, such that readDec no longer gives a clean parse.","type_of_failure":"OtherFailure","blocking":[]} -->https://gitlab.haskell.org/ghc/ghc/-/issues/7599timeout does not behave as expected2019-07-07T18:49:03Ziquetimeout does not behave as expectedIn trying to debug an error I found using the MongoDB package (it was refusing connections) I found what I believe is a bug with System.Timeout.
When connecting with connectTo I immediately get a handle, wrapped in timeout with a positi...In trying to debug an error I found using the MongoDB package (it was refusing connections) I found what I believe is a bug with System.Timeout.
When connecting with connectTo I immediately get a handle, wrapped in timeout with a positive timeout, it instantly returns Nothing. When using a negative timeout (wait indefinitely) it instantly returns the proper Handle.
Below is a minimal test-case that I ran in ghci.
Import System.Timeout
Import Network
timeout (-1) $ connectTo "127.0.0.1" (PortNumber 27017)
-- This returns: Just {handle: \<socket: 9\>}
timeout 1000000 $ connectTo "127.0.0.1" (PortNumber 27017)
-- This returns Nothing
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | -------------- |
| Version | 7.6.1 |
| Type | Bug |
| TypeOfFailure | OtherFailure |
| Priority | normal |
| Resolution | Unresolved |
| Component | libraries/base |
| Test case | |
| Differential revisions | |
| BlockedBy | |
| Related | |
| Blocking | |
| CC | |
| Operating system | |
| Architecture | |
</details>
<!-- {"blocked_by":[],"summary":"timeout does not behave as expected","status":"New","operating_system":"","component":"libraries/base","related":[],"milestone":"","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"7.6.1","keywords":["System.Timeout","base-4.6","timeout"],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"Bug","description":"In trying to debug an error I found using the MongoDB package (it was refusing connections) I found what I believe is a bug with System.Timeout.\r\n\r\nWhen connecting with connectTo I immediately get a handle, wrapped in timeout with a positive timeout, it instantly returns Nothing. When using a negative timeout (wait indefinitely) it instantly returns the proper Handle.\r\n\r\nBelow is a minimal test-case that I ran in ghci.\r\n\r\nImport System.Timeout\r\n\r\nImport Network\r\n\r\ntimeout (-1) $ connectTo \"127.0.0.1\" (PortNumber 27017)\r\n -- This returns: Just {handle: <socket: 9>}\r\n\r\ntimeout 1000000 $ connectTo \"127.0.0.1\" (PortNumber 27017)\r\n -- This returns Nothing","type_of_failure":"OtherFailure","blocking":[]} -->https://gitlab.haskell.org/ghc/ghc/-/issues/7589LLVM 3.2 Support2019-07-07T18:49:06ZdtereiLLVM 3.2 SupportLLVM 3.2 is out as of mid December. We need to update the backend to support it.
There seems to be a number of new bugs due to the change.
With LLVM 3.1 we get the following testsuite failures:
```
OVERALL SUMMARY for test run started...LLVM 3.2 is out as of mid December. We need to update the backend to support it.
There seems to be a number of new bugs due to the change.
With LLVM 3.1 we get the following testsuite failures:
```
OVERALL SUMMARY for test run started at Mon Jan 14 21:42:32 PST 2013
3552 total tests, which gave rise to
13164 test cases, of which
0 caused framework failures
11606 were skipped
1515 expected passes
23 had missing libraries
15 expected failures
0 unexpected passes
5 unexpected failures
Unexpected failures:
* codeGen/should_run cgrun044 [exit code non-0] (optllvm)
* concurrent/should_run 367_letnoescape [bad exit code] (optllvm)
* numeric/should_run arith005 [bad stdout] (optllvm)
typecheck/should_compile tc226 [exit code non-0] (optllvm)
typecheck/should_compile tc235 [exit code non-0] (optllvm)
```
Where the failures marked with '\*' are unique to the LLVM backend.
With LLVM 3.2 we get the following:
```
OVERALL SUMMARY for test run started at Tue Jan 15 16:02:01 PST 2013
3552 total tests, which gave rise to
13164 test cases, of which
0 caused framework failures
11606 were skipped
1512 expected passes
23 had missing libraries
15 expected failures
0 unexpected passes
8 unexpected failures
Unexpected failures:
** codeGen/should_compile 1916 [exit code non-0] (optllvm)
** codeGen/should_run cgrun028 [exit code non-0] (optllvm)
* codeGen/should_run cgrun044 [exit code non-0] (optllvm)
* concurrent/should_run 367_letnoescape [bad exit code] (optllvm)
* numeric/should_run arith005 [bad stdout] (optllvm)
** numeric/should_run numrun012 [exit code non-0] (optllvm)
typecheck/should_compile tc226 [exit code non-0] (optllvm)
typecheck/should_compile tc235 [exit code non-0] (optllvm)
```
Where failures marked with '\*' are unique to the LLVM backend and failures marked with '\*\*' are unique to LLVM 3.2 relative to 3.1.
I believe bootstrapping with LLVM also fails now. However, that may be due to the change to the new-code-generator, and not of LLVM 3.1 -\> 3.2. I'll create a separate ticket for that.
**NOTE**: These test suite results were all generated on **Mac OS X 10.8**.dtereidtereihttps://gitlab.haskell.org/ghc/ghc/-/issues/7583IO reordering2019-07-07T18:49:08ZHeimdellIO reorderingI have a simple test program:
```
main = do putStr "> "
line <- getLine
putStrLn line
```
In ghci, it writes "\> " before receiving input:
```
Prelude Main> main
> WHAT
WHAT
```
But being compiled by ghc it writes...I have a simple test program:
```
main = do putStr "> "
line <- getLine
putStrLn line
```
In ghci, it writes "\> " before receiving input:
```
Prelude Main> main
> WHAT
WHAT
```
But being compiled by ghc it writes "\> " just after receiving input.
```
maelstrom@ubuntu:~/vault$ ./test
WHAT
> WHAT
```
That is not the behavior I expect.
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | ------------ |
| Version | 7.4.1 |
| Type | Bug |
| TypeOfFailure | OtherFailure |
| Priority | normal |
| Resolution | Unresolved |
| Component | Compiler |
| Test case | |
| Differential revisions | |
| BlockedBy | |
| Related | |
| Blocking | |
| CC | |
| Operating system | |
| Architecture | |
</details>
<!-- {"blocked_by":[],"summary":"IO reordering","status":"New","operating_system":"","component":"Compiler","related":[],"milestone":"","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"7.4.1","keywords":["IO,","evaluation","invalid","order"],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"Bug","description":"I have a simple test program:\r\n\r\n{{{\r\nmain = do putStr \"> \"\r\n line <- getLine\r\n putStrLn line\r\n}}}\r\n\r\nIn ghci, it writes \"> \" before receiving input:\r\n\r\n{{{\r\nPrelude Main> main\r\n> WHAT\r\nWHAT\r\n}}}\r\n\r\nBut being compiled by ghc it writes \"> \" just after receiving input.\r\n\r\n{{{\r\nmaelstrom@ubuntu:~/vault$ ./test \r\nWHAT\r\n> WHAT\r\n}}}\r\n\r\nThat is not the behavior I expect.","type_of_failure":"OtherFailure","blocking":[]} -->https://gitlab.haskell.org/ghc/ghc/-/issues/7537[PATCH] Incorrect Haskell type for ino_t on MacOS X 10.52019-07-07T18:49:19ZPHO[PATCH] Incorrect Haskell type for ino_t on MacOS X 10.5I found a strange problem that `System.Posix.Internals.fdStat` reporting `st_ino == 0` for any file. That was because `__hscore_st_ino` was assuming `ino_t` to be `uint64_t` while `CIno` being inferred to be `Word32`.
Here is my [patch]...I found a strange problem that `System.Posix.Internals.fdStat` reporting `st_ino == 0` for any file. That was because `__hscore_st_ino` was assuming `ino_t` to be `uint64_t` while `CIno` being inferred to be `Word32`.
Here is my [patch](https://github.com/phonohawk/packages-base/commit/7ccbbb4e9e9b9617eb698eb92ef20a1052af38b9) to fix this:
```
git fetch git://github.com/phonohawk/packages-base.git darwin-htype-ino_t
```
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | -------------- |
| Version | 7.7 |
| Type | Bug |
| TypeOfFailure | OtherFailure |
| Priority | normal |
| Resolution | Unresolved |
| Component | libraries/base |
| Test case | |
| Differential revisions | |
| BlockedBy | |
| Related | |
| Blocking | |
| CC | |
| Operating system | |
| Architecture | |
</details>
<!-- {"blocked_by":[],"summary":"[PATCH] Incorrect Haskell type for ino_t on MacOS X 10.5","status":"New","operating_system":"","component":"libraries/base","related":[],"milestone":"","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"7.7","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"Bug","description":"I found a strange problem that `System.Posix.Internals.fdStat` reporting `st_ino == 0` for any file. That was because `__hscore_st_ino` was assuming `ino_t` to be `uint64_t` while `CIno` being inferred to be `Word32`.\r\n\r\nHere is my [https://github.com/phonohawk/packages-base/commit/7ccbbb4e9e9b9617eb698eb92ef20a1052af38b9 patch] to fix this:\r\n{{{\r\ngit fetch git://github.com/phonohawk/packages-base.git darwin-htype-ino_t\r\n}}}","type_of_failure":"OtherFailure","blocking":[]} -->https://gitlab.haskell.org/ghc/ghc/-/issues/7528Non terminating thunk resolution blocks world, even in the case of forkOS2019-07-07T18:49:20ZtimthelionNon terminating thunk resolution blocks world, even in the case of forkOSPlease see:
http://comments.gmane.org/gmane.comp.lang.haskell.cafe/102479
> {-\# LANGUAGE ScopedTypeVariables \#-}
> import Control.Concurrent
> main = do
> putStrLn "Hello"
> forkOS neverEnds
> putStrLn "Bye bye" --We never get here(o...Please see:
http://comments.gmane.org/gmane.comp.lang.haskell.cafe/102479
> {-\# LANGUAGE ScopedTypeVariables \#-}
> import Control.Concurrent
> main = do
> putStrLn "Hello"
> forkOS neverEnds
> putStrLn "Bye bye" --We never get here(or at least I don't).
> neverEnds = do
> let (a::String) = a
> putStrLn a
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | -------------- |
| Version | 7.4.2 |
| Type | Bug |
| TypeOfFailure | OtherFailure |
| Priority | normal |
| Resolution | Unresolved |
| Component | Runtime System |
| Test case | |
| Differential revisions | |
| BlockedBy | |
| Related | |
| Blocking | |
| CC | |
| Operating system | |
| Architecture | x86_64 (amd64) |
</details>
<!-- {"blocked_by":[],"summary":"Non terminating thunk resolution blocks world, even in the case of forkOS","status":"New","operating_system":"","component":"Runtime System","related":[],"milestone":"","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"7.4.2","keywords":["Concurrent","forkOS","thunk"],"differentials":[],"test_case":"","architecture":"x86_64 (amd64)","cc":[""],"type":"Bug","description":"Please see:\r\nhttp://comments.gmane.org/gmane.comp.lang.haskell.cafe/102479\r\n\r\n>{-# LANGUAGE ScopedTypeVariables #-}\r\n>import Control.Concurrent\r\n\r\n>main = do\r\n> putStrLn \"Hello\"\r\n> forkOS neverEnds\r\n> putStrLn \"Bye bye\" --We never get here(or at least I don't).\r\n\r\n>neverEnds = do\r\n> let (a::String) = a\r\n> putStrLn a","type_of_failure":"OtherFailure","blocking":[]} -->https://gitlab.haskell.org/ghc/ghc/-/issues/7493STM and TVar report incorrect results2019-07-07T18:49:30ZparcsSTM and TVar report incorrect resultsOn Haskell Cafe, I posted:
I'm getting strange behavior when using the 'many' combinator to read zero or more items off of a TQueue with readTQueue. The script that exhibits this behavior is as follows:
```
import Control.Concurrent.ST...On Haskell Cafe, I posted:
I'm getting strange behavior when using the 'many' combinator to read zero or more items off of a TQueue with readTQueue. The script that exhibits this behavior is as follows:
```
import Control.Concurrent.STM
import Control.Concurrent
import Control.Monad
import Control.Applicative
main = do
q <- newTQueueIO
atomically $ writeTQueue q True
atomically $ writeTQueue q False
forever $ do
xs <- atomically $ many $ readTQueue q
print xs
threadDelay 500000
```
I'd expect the output of the script to be:
```
[True,False]
[]
[]
...
```
However, that is not the case: the actual output of the script is:
```
[True,False]
[True,False]
[True,False]
...
```
If 1 element (say, True) is written into the TQueue instead of 2, then the output of the script is:
```
[True]
[]
[]
...
```
Which is expected behavior, but inconsistent with the behavior when the TQueue has 2 or more elements in it.
Is this considered a bug, or undocumented behavior of TQueue?
----
Bas vas Dijk noted that this may be a bug in STM, and provided a condensed test case which reproduces the behavior of my original script:
```
$ cat stmTest.hs
import Control.Concurrent.STM
main = do
x <- atomically $ do
t <- newTVar 1
writeTVar t 2
((readTVar t >> retry) `orElse` return ()) `orElse` return ()
readTVar t
print x
$ ghc --make stmTest.hs -fforce-recomp -threaded -o stmTest && ./stmTest
[1 of 1] Compiling Main ( stmTest.hs, stmTest.o )
Linking stmTest ...
1
```
The program prints 1 when it should print 2.
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | -------------------- |
| Version | 7.6.1 |
| Type | Bug |
| TypeOfFailure | OtherFailure |
| Priority | normal |
| Resolution | Unresolved |
| Component | Runtime System |
| Test case | |
| Differential revisions | |
| BlockedBy | |
| Related | |
| Blocking | |
| CC | v.dijk.bas@gmail.com |
| Operating system | |
| Architecture | |
</details>
<!-- {"blocked_by":[],"summary":"STM and TVar report incorrect results","status":"New","operating_system":"","component":"Runtime System","related":[],"milestone":"","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"7.6.1","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":["v.dijk.bas@gmail.com"],"type":"Bug","description":"On Haskell Cafe, I posted:\r\n\r\nI'm getting strange behavior when using the 'many' combinator to read zero or more items off of a TQueue with readTQueue. The script that exhibits this behavior is as follows:\r\n\r\n{{{\r\nimport Control.Concurrent.STM\r\nimport Control.Concurrent\r\nimport Control.Monad\r\nimport Control.Applicative\r\n\r\nmain = do\r\n q <- newTQueueIO\r\n atomically $ writeTQueue q True\r\n atomically $ writeTQueue q False\r\n forever $ do\r\n xs <- atomically $ many $ readTQueue q\r\n print xs\r\n threadDelay 500000\r\n}}}\r\n\r\nI'd expect the output of the script to be:\r\n{{{\r\n[True,False]\r\n[]\r\n[]\r\n...\r\n}}}\r\n\r\nHowever, that is not the case: the actual output of the script is:\r\n{{{\r\n[True,False]\r\n[True,False]\r\n[True,False]\r\n...\r\n}}}\r\n\r\nIf 1 element (say, True) is written into the TQueue instead of 2, then the output of the script is:\r\n{{{\r\n[True]\r\n[]\r\n[]\r\n...\r\n}}}\r\n\r\nWhich is expected behavior, but inconsistent with the behavior when the TQueue has 2 or more elements in it.\r\n\r\nIs this considered a bug, or undocumented behavior of TQueue?\r\n\r\n----\r\n\r\nBas vas Dijk noted that this may be a bug in STM, and provided a condensed test case which reproduces the behavior of my original script:\r\n\r\n{{{\r\n$ cat stmTest.hs\r\nimport Control.Concurrent.STM\r\nmain = do\r\n x <- atomically $ do\r\n t <- newTVar 1\r\n writeTVar t 2\r\n ((readTVar t >> retry) `orElse` return ()) `orElse` return ()\r\n readTVar t\r\n print x\r\n\r\n$ ghc --make stmTest.hs -fforce-recomp -threaded -o stmTest && ./stmTest\r\n[1 of 1] Compiling Main ( stmTest.hs, stmTest.o )\r\nLinking stmTest ...\r\n1\r\n}}}\r\n\r\nThe program prints 1 when it should print 2.","type_of_failure":"OtherFailure","blocking":[]} -->7.6.2https://gitlab.haskell.org/ghc/ghc/-/issues/7491getNumCapabilities uses n_capabilities instead of enabled_capabilities2019-07-07T18:49:31ZYurasgetNumCapabilities uses n_capabilities instead of enabled_capabilitiessetNumCapabilities newer removes capabilities, it just disables them when new value is less the the current one. In that case getNumCapabilities returns wrong result.
<details><summary>Trac metadata</summary>
| Trac field |...setNumCapabilities newer removes capabilities, it just disables them when new value is less the the current one. In that case getNumCapabilities returns wrong result.
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | -------------------- |
| Version | 7.6.1 |
| Type | Bug |
| TypeOfFailure | OtherFailure |
| Priority | normal |
| Resolution | Unresolved |
| Component | libraries/base |
| Test case | |
| Differential revisions | |
| BlockedBy | |
| Related | |
| Blocking | |
| CC | shumovichy@gmail.com |
| Operating system | |
| Architecture | |
</details>
<!-- {"blocked_by":[],"summary":"getNumCapabilities uses n_capabilities instead of enabled_capabilities","status":"New","operating_system":"","component":"libraries/base","related":[],"milestone":"","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"7.6.1","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":["shumovichy@gmail.com"],"type":"Bug","description":"setNumCapabilities newer removes capabilities, it just disables them when new value is less the the current one. In that case getNumCapabilities returns wrong result.","type_of_failure":"OtherFailure","blocking":[]} -->7.8.1https://gitlab.haskell.org/ghc/ghc/-/issues/7483Broken Read instance for Data.Fixed ("no parse" in legitimate cases).2019-07-07T18:49:32ZnavaatiBroken Read instance for Data.Fixed ("no parse" in legitimate cases).`read "Just 12.30" :: Maybe Centi` throws "\*\*\* Exception: Prelude.read: no parse", as do `read " 12.30" :: Centi`.
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------...`read "Just 12.30" :: Maybe Centi` throws "\*\*\* Exception: Prelude.read: no parse", as do `read " 12.30" :: Centi`.
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | ---------------------- |
| Version | 7.6.1 |
| Type | Bug |
| TypeOfFailure | OtherFailure |
| Priority | normal |
| Resolution | Unresolved |
| Component | libraries/base |
| Test case | |
| Differential revisions | |
| BlockedBy | |
| Related | |
| Blocking | |
| CC | leo.gillot@navaati.net |
| Operating system | |
| Architecture | |
</details>
<!-- {"blocked_by":[],"summary":"Broken Read instance for Data.Fixed (\"no parse\" in legitimate cases).","status":"New","operating_system":"","component":"libraries/base","related":[],"milestone":"","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"7.6.1","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":["leo.gillot@navaati.net"],"type":"Bug","description":"{{{read \"Just 12.30\" :: Maybe Centi}}} throws \"*** Exception: Prelude.read: no parse\", as do {{{read \" 12.30\" :: Centi}}}.","type_of_failure":"OtherFailure","blocking":[]} -->https://gitlab.haskell.org/ghc/ghc/-/issues/7468incorect waiting for packets on UDP connections.2019-07-07T18:49:37ZETincorect waiting for packets on UDP connections.Preconditions:
Have an UDP server.
Transform the socket into a handle.
call hWaitForInput.
When it returns True.
call recv to read the datagram.
Expected result:
it will wait for a package with the hWaitForInput.
when the package arrive...Preconditions:
Have an UDP server.
Transform the socket into a handle.
call hWaitForInput.
When it returns True.
call recv to read the datagram.
Expected result:
it will wait for a package with the hWaitForInput.
when the package arrives (withing the timeout).
it will read it in the buffer.
(this is how it works in HUGS).
Actual result:
hWaitForInput consumes the package (I think).
recv will block until the next package arrives.
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | -------------- |
| Version | 7.4.1 |
| Type | Bug |
| TypeOfFailure | OtherFailure |
| Priority | normal |
| Resolution | Unresolved |
| Component | libraries/base |
| Test case | |
| Differential revisions | |
| BlockedBy | |
| Related | |
| Blocking | |
| CC | |
| Operating system | |
| Architecture | |
</details>
<!-- {"blocked_by":[],"summary":"incorect waiting for packets on UDP connections.","status":"New","operating_system":"","component":"libraries/base","related":[],"milestone":"","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"7.4.1","keywords":["UDP","loss.","packet"],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"Bug","description":"Preconditions:\r\nHave an UDP server.\r\nTransform the socket into a handle.\r\ncall hWaitForInput.\r\nWhen it returns True.\r\ncall recv to read the datagram.\r\n\r\nExpected result:\r\nit will wait for a package with the hWaitForInput.\r\nwhen the package arrives (withing the timeout).\r\nit will read it in the buffer.\r\n(this is how it works in HUGS).\r\n\r\nActual result:\r\nhWaitForInput consumes the package (I think).\r\nrecv will block until the next package arrives.","type_of_failure":"OtherFailure","blocking":[]} -->https://gitlab.haskell.org/ghc/ghc/-/issues/7421Data.List.insert / insertBy do not match the documentation2019-07-07T18:49:48ZBart MasseyData.List.insert / insertBy do not match the documentationIn Data.List from base 4.6.0.0 (as in every previous version), the documentation for insert says "The insert function takes an element and a list and inserts the element into the list at the last position where it is still less than or e...In Data.List from base 4.6.0.0 (as in every previous version), the documentation for insert says "The insert function takes an element and a list and inserts the element into the list at the last position where it is still less than or equal to the next element." However:
> insert 1 \[2,3,4,2,3,4\]
\[1,2,3,4,2,3,4\]
One could correct the code to match the documentation. However, any maximally productive version is likely quite a bit less efficient than the current code, and the documented behavior doesn't seem terribly useful.
Instead, I suggest patching the documentation in the obvious way: "The insert function takes an element and a list and inserts the element into the list at the first position where it is less than or equal to the next element."
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | -------------- |
| Version | 7.6.1 |
| Type | Bug |
| TypeOfFailure | OtherFailure |
| Priority | normal |
| Resolution | Unresolved |
| Component | libraries/base |
| Test case | |
| Differential revisions | |
| BlockedBy | |
| Related | |
| Blocking | |
| CC | |
| Operating system | |
| Architecture | |
</details>
<!-- {"blocked_by":[],"summary":"Data.List.insert / insertBy do not match the documentation","status":"New","operating_system":"","component":"libraries/base","related":[],"milestone":"","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"7.6.1","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"Bug","description":"In Data.List from base 4.6.0.0 (as in every previous version), the documentation for insert says \"The insert function takes an element and a list and inserts the element into the list at the last position where it is still less than or equal to the next element.\" However:\r\n\r\n> insert 1 [2,3,4,2,3,4]\r\n[1,2,3,4,2,3,4]\r\n\r\nOne could correct the code to match the documentation. However, any maximally productive version is likely quite a bit less efficient than the current code, and the documented behavior doesn't seem terribly useful.\r\n\r\nInstead, I suggest patching the documentation in the obvious way: \"The insert function takes an element and a list and inserts the element into the list at the first position where it is less than or equal to the next element.\"","type_of_failure":"OtherFailure","blocking":[]} -->7.6.2https://gitlab.haskell.org/ghc/ghc/-/issues/7399Test Posix004 fails in test-suite2019-07-07T18:49:54ZpaulhTest Posix004 fails in test-suiteAfter a standard build of ghc-7.6.1 on debian wheezy, the test-suite fails on the test posix004.
The error given is:
```
Wrong exit code (expected 0 , actual 1 )
Stdout:
Stderr:
posix004: unexpected termination cause
*** unexpected f...After a standard build of ghc-7.6.1 on debian wheezy, the test-suite fails on the test posix004.
The error given is:
```
Wrong exit code (expected 0 , actual 1 )
Stdout:
Stderr:
posix004: unexpected termination cause
*** unexpected failure for posix004(normal)
```7.8.1Edward Z. YangEdward Z. Yang