- ghc-tickets - Haskell.org

Re: [GHC] #1487: unix package: test needed for getLoginName
by GHC 26 Jun '14

26 Jun '14

#1487: unix package: test needed for getLoginName -------------------------------------+------------------------------------- Reporter: simonmar | Owner: thomie Type: bug | Status: patch Priority: lowest | Milestone: Component: libraries/unix | Version: Resolution: | Keywords: Operating System: Linux | Architecture: Unknown/Multiple Type of failure: Incorrect result | Difficulty: Easy (less than 1 at runtime | hour) Test Case: | Blocked By: Blocking: | Related Tickets: -------------------------------------+------------------------------------- Changes (by thomie): * status: new => patch * version: 6.6.1 => * milestone: 7.6.2 => -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/1487#comment:20> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

Re: [GHC] #1487: unix package: test needed for getLoginName
by GHC 26 Jun '14

26 Jun '14

#1487: unix package: test needed for getLoginName -------------------------------------+------------------------------------- Reporter: simonmar | Owner: thomie Type: bug | Status: new Priority: lowest | Milestone: 7.6.2 Component: libraries/unix | Version: 6.6.1 Resolution: | Keywords: Operating System: Linux | Architecture: Unknown/Multiple Type of failure: Incorrect result | Difficulty: Easy (less than 1 at runtime | hour) Test Case: | Blocked By: Blocking: | Related Tickets: -------------------------------------+------------------------------------- Comment (by thomie): The attached patch fixes this issue. I tried going the pseudo-terminal route, but it doesn't work. System.Posix.User's `getLoginName` calls the C function `getlogin`. This function, on GNU/Linux at least, looks in the file /var/run/utmp for a login record with a tty name that matches that of the terminal connected to stdin (filedescriptor 0). It is possible to trick `getlogin` to check a pseudo terminal's name with something like: (master, slave) <- openPseudoTerminal dupTo master stdInput But, as far as I understand, pseudo-terminals are never registered in /var/run/utmp. Therefore `getlogin` will not find the user's login name and just return 'No such file or directory'. Maybe better than 'Inappropriate ioctl for device', but still an error. What does work, surprisingly, is adding this to `user001.hs`: dupTo stdOutput stdInput , but only if we wouldn't redirect stdout as well. The same for stderr. The solution is to simply not redirect stdin (i.e. don't do ./user001 < /dev/null). This implies skipping the ghci way. The commit that introduced the `no_stdin` test option alluded to this as well: fa52a8c9d8eae5e3fc4c0cf0e5672875e161e05c. One general concern is that there are no guarantees that `getlogin` will return anything other than NULL, so the test with this patch applied might fail on some systems. Another option therefore would be to turn the getLoginName test back off again, document why, and close this issue regardless. Review of -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/1487#comment:19> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

Re: [GHC] #1487: unix package: test needed for getLoginName
by GHC 26 Jun '14

26 Jun '14

#1487: unix package: test needed for getLoginName -------------------------------------+------------------------------------- Reporter: simonmar | Owner: thomie Type: bug | Status: new Priority: lowest | Milestone: 7.6.2 Component: libraries/unix | Version: 6.6.1 Resolution: | Keywords: Operating System: Linux | Architecture: Unknown/Multiple Type of failure: Incorrect result | Difficulty: Easy (less than 1 at runtime | hour) Test Case: | Blocked By: Blocking: | Related Tickets: -------------------------------------+------------------------------------- Changes (by thomie): * owner: adrien => thomie -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/1487#comment:18> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

Re: [GHC] #3032: would be nice if -fno-code and --make worked together
by GHC 26 Jun '14

26 Jun '14

#3032: would be nice if -fno-code and --make worked together -------------------------------------+------------------------------------ Reporter: duncan | Owner: Type: feature request | Status: closed Priority: lowest | Milestone: 7.6.2 Component: Compiler | Version: 6.8.2 Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: None/Unknown | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: -------------------------------------+------------------------------------ Comment (by tibbe): To make it work with Cabal we need to make -no-code a Cabal flag (that gets converted to a GHC flag). Right now it's opaque to Cabal what's going on. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/3032#comment:10> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

Re: [GHC] #3032: would be nice if -fno-code and --make worked together
by GHC 26 Jun '14

26 Jun '14

#3032: would be nice if -fno-code and --make worked together -------------------------------------+------------------------------------ Reporter: duncan | Owner: Type: feature request | Status: closed Priority: lowest | Milestone: 7.6.2 Component: Compiler | Version: 6.8.2 Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: None/Unknown | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: -------------------------------------+------------------------------------ Changes (by ezyang): * status: new => closed * failure: => None/Unknown * resolution: => fixed Comment: I think this works now, modulo Cabal support: {{{ ezyang@sabre:~/Dev/labs$ cabal unpack parsec cd Unpacking to parsec-3.1.5/ ezyang@sabre:~/Dev/labs$ cd parsec-3.1.5/ ezyang@sabre:~/Dev/labs/parsec-3.1.5$ cabal configure --ghc-option=-fno- code Resolving dependencies... Configuring parsec-3.1.5... ezyang@sabre:~/Dev/labs/parsec-3.1.5$ time cabal build Building parsec-3.1.5... Preprocessing library parsec-3.1.5... [ 1 of 25] Compiling Text.Parsec.Pos ( Text/Parsec/Pos.hs, nothing ) [ 2 of 25] Compiling Text.Parsec.Error ( Text/Parsec/Error.hs, nothing ) [ 3 of 25] Compiling Text.ParserCombinators.Parsec.Error ( Text/ParserCombinators/Parsec/Error.hs, nothing ) [ 4 of 25] Compiling Text.ParserCombinators.Parsec.Pos ( Text/ParserCombinators/Parsec/Pos.hs, nothing ) [ 5 of 25] Compiling Text.Parsec.Prim ( Text/Parsec/Prim.hs, nothing ) [ 6 of 25] Compiling Text.Parsec.Char ( Text/Parsec/Char.hs, nothing ) [ 7 of 25] Compiling Text.Parsec.Combinator ( Text/Parsec/Combinator.hs, nothing ) [ 8 of 25] Compiling Text.ParserCombinators.Parsec.Combinator ( Text/ParserCombinators/Parsec/Combinator.hs, nothing ) [ 9 of 25] Compiling Text.Parsec.String ( Text/Parsec/String.hs, nothing ) [10 of 25] Compiling Text.ParserCombinators.Parsec.Char ( Text/ParserCombinators/Parsec/Char.hs, nothing ) [11 of 25] Compiling Text.Parsec.ByteString ( Text/Parsec/ByteString.hs, nothing ) [12 of 25] Compiling Text.Parsec.ByteString.Lazy ( Text/Parsec/ByteString/Lazy.hs, nothing ) [13 of 25] Compiling Text.Parsec.Text ( Text/Parsec/Text.hs, nothing ) [14 of 25] Compiling Text.Parsec.Text.Lazy ( Text/Parsec/Text/Lazy.hs, nothing ) [15 of 25] Compiling Text.Parsec.Token ( Text/Parsec/Token.hs, nothing ) [16 of 25] Compiling Text.ParserCombinators.Parsec.Token ( Text/ParserCombinators/Parsec/Token.hs, nothing ) [17 of 25] Compiling Text.Parsec.Expr ( Text/Parsec/Expr.hs, nothing ) [18 of 25] Compiling Text.ParserCombinators.Parsec.Prim ( Text/ParserCombinators/Parsec/Prim.hs, nothing ) [19 of 25] Compiling Text.ParserCombinators.Parsec ( Text/ParserCombinators/Parsec.hs, nothing ) [20 of 25] Compiling Text.ParserCombinators.Parsec.Expr ( Text/ParserCombinators/Parsec/Expr.hs, nothing ) [21 of 25] Compiling Text.Parsec ( Text/Parsec.hs, nothing ) [22 of 25] Compiling Text.Parsec.Language ( Text/Parsec/Language.hs, nothing ) [23 of 25] Compiling Text.ParserCombinators.Parsec.Language ( Text/ParserCombinators/Parsec/Language.hs, nothing ) [24 of 25] Compiling Text.Parsec.Perm ( Text/Parsec/Perm.hs, nothing ) [25 of 25] Compiling Text.ParserCombinators.Parsec.Perm ( Text/ParserCombinators/Parsec/Perm.hs, nothing ) /usr/bin/ar: dist/build/Text/Parsec.o: No such file or directory real 0m2.110s user 0m1.682s sys 0m0.281s }}} -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/3032#comment:9> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

[GHC] #9231: 7.8 regression in Read instance of Data.Fixed.Pico
by GHC 26 Jun '14

26 Jun '14

#9231: 7.8 regression in Read instance of Data.Fixed.Pico ------------------------------------+------------------------------------- Reporter: leonbaum2 | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: libraries/base | Version: 7.8.2 Keywords: | Operating System: Unknown/Multiple Architecture: Unknown/Multiple | Type of failure: None/Unknown Difficulty: Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | ------------------------------------+------------------------------------- If I run the following with ghc-7.8.2, the runtime system eats up all of my memory and doesn't produce a result: read "1" :: Data.Fixed.Pico -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/9231> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 12

[GHC] #9239: Program loops in syscall retries cancelled by rt_sigreturn signal
by GHC 25 Jun '14

25 Jun '14

#9239: Program loops in syscall retries cancelled by rt_sigreturn signal --------------------------+------------------------------------------------ Reporter: k-bx | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: | Version: 7.8.2 Compiler | Operating System: Unknown/Multiple Keywords: | Type of failure: Incorrect result at runtime Architecture: | Test Case: Unknown/Multiple | Blocking: Difficulty: | Unknown | Blocked By: | Related Tickets: | --------------------------+------------------------------------------------ Sorry if this bug is not related to ghc, but it seems to me that it might be. Originally I reported it against hedis package, you can find description in it's bug tracker https://github.com/informatikr/hedis/issues/15 Short recap: one specific operation against redis database (zrangebyscoreLimit against big ZSET), program behaves differently. For me, most of the time it would hang, sometimes it succeeds, sometimes outputs "ConnectionLost" twice and dies. My environments are: Ubuntu 12.04/14.04, redis versions tested are 2.2 through 2.8 (latest in each even branch). Under GHC 7.6 and profiling enabled, strace would end up showing an infinite loop of these operations: {{{ --- SIGVTALRM {si_signo=SIGVTALRM, si_code=SI_TIMER, si_pid=0, si_uid=0, si_value=0} --- rt_sigreturn() = -1 EINTR (Interrupted system call) select(4, [3], [], NULL, NULL) = ? ERESTARTNOHAND (To be restarted if no handler) }}} Under 7.8.2 profiling enabled, it would also loop, but in few seconds it would hang, produring these last lines of output (plus result of Ctrl+C): {{{ select(4, [3], [], NULL, NULL) = ? ERESTARTNOHAND (To be restarted if no handler) --- SIGVTALRM {si_signo=SIGVTALRM, si_code=SI_TIMER, si_pid=0, si_uid=0, si_value=0} --- timer_settime(0, 0, {it_interval={0, 0}, it_value={0, 0}}, NULL) = 0 rt_sigreturn() = -1 EINTR (Interrupted system call) select(4, [3], [], NULL, NULL^CProcess 16483 detached <detached ...> }}} With profiling disabled on 7.8.2 it would sometimes hang same way as with profiling, but sometimes it would finish with outputting "ConnectionLost" errors (you can find links to full strace output in github hedis issue page linked above). Sorry again if it's not related to GHC, meanwhile I'll try to investigate further. Thank you. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/9239> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 2

[GHC] #8972: Investigate adding fast compare-and-swap Int type/primops
by GHC 24 Jun '14

24 Jun '14

#8972: Investigate adding fast compare-and-swap Int type/primops ------------------------------------+------------------------------------- Reporter: tibbe | Owner: tibbe Type: feature request | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.9 Keywords: | Operating System: Unknown/Multiple Architecture: Unknown/Multiple | Type of failure: None/Unknown Difficulty: Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | ------------------------------------+------------------------------------- I've received reports that using `IORef Int` and `atomicModifyIORef` to implement an atomic counter in the ekg package has become a bottleneck for some of its users. These users update the counter thousands of times per second, using multiple threads. I will investigate whether adding a dedicated atomic `Int` reference type will offer significant speed improvements. Such a type can also be used to implement cheaper locks (by using bits in the int to represent different lock states, such as reader/write locks.) Lets call this new type `AtomicIntRef` for now. This new type needs to support at least these functions: {{{#!haskell add :: AtomicIntRef -> Int -> IO Int set :: AtomicIntRef -> Int -> IO () get :: AtomicIntRef -> IO Int }}} `add` would be implemented using the `lock` and `xaddq` instructions. `set` and `get` are just simple loads and stores on x86, as these are atomic. We might also want to consider having other functions, such as a `cas`. Furthermore, there are subtleties with memory barriers that might motivate having barrier/barrier-less versions of some functions. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/8972> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 14

Re: [GHC] #7200: template-haskell-2.7.0.0 fails to build with GHC 7.0.4 due to missing pragma
by GHC 24 Jun '14

24 Jun '14

#7200: template-haskell-2.7.0.0 fails to build with GHC 7.0.4 due to missing pragma -------------------------------------+------------------------------------ Reporter: tibbe | Owner: duncan Type: bug | Status: closed Priority: normal | Milestone: 7.10.1 Component: Template Haskell | Version: 7.0.4 Resolution: wontfix | Keywords: Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: None/Unknown | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: -------------------------------------+------------------------------------ Changes (by tibbe): * status: new => closed * resolution: => wontfix Comment: 7.0.4 is quite old now and we have a way to make sure template-haskell doesn't get upgraded by cabal. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/7200#comment:12> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

[GHC] #9232: Stats file has wrong numbers
by GHC 24 Jun '14

24 Jun '14

#9232: Stats file has wrong numbers ------------------------------------+----------------------------- Reporter: augustss | Owner: simonmar Type: bug | Status: new Priority: low | Milestone: Component: Runtime System | Version: 7.8.2 Keywords: | Operating System: Windows Architecture: Unknown/Multiple | Type of failure: Other Difficulty: Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | ------------------------------------+----------------------------- The summary numbers in the file generated with the -S flag cannot be right. Here's an example: {{{ 1,943,795,468 bytes allocated in the heap 17,587,189,232 bytes copied during GC }}} The corresponding numbers with ghc 7.2 are {{{ 193,859,474,520 bytes allocated in the heap 17,766,908,288 bytes copied during GC }}} While it's theoretically possible that allocation has improved that much, I don't believe it. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/9232> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 5