- ghc-tickets - Haskell.org

Re: [GHC] #3649: inconsistent exception between unix/windows for running non-existant program
by GHC 30 Jul '13

30 Jul '13

#3649: inconsistent exception between unix/windows for running non-existant program --------------------------------------+------------------------------------ Reporter: duncan | Owner: Type: bug | Status: new Priority: low | Milestone: 7.6.2 Component: libraries/process | Version: 6.10.4 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: None/Unknown | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: --------------------------------------+------------------------------------ Changes (by duncan): * status: closed => new * resolution: fixed => Comment: Note that the C code still says (roughly): {{{ if (close_fds) { int i; // XXX Not the pipe for (i = 3; i < max_fd; i++) { close(i); } } }}} Which means that this nice new error handling will (I think) go wrong in the `CreateProcess { close_fds = True }` case. Should be easy to fix, just something like... {{{ for (i = 3; i < max_fd; i++) { if (i != forkCommunicationFds[1]) { close(i); } } }}} -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/3649#comment:10> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

Re: [GHC] #7978: Profiling broken
by GHC 30 Jul '13

30 Jul '13

#7978: Profiling broken --------------------------------------------+------------------------------ Reporter: gmainland | Owner: Type: bug | Status: new Priority: highest | Milestone: 7.8.1 Component: Compiler | Version: 7.7 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: GHC doesn't work at all | Unknown/Multiple Test Case: | Difficulty: Unknown Blocking: | Blocked By: | Related Tickets: --------------------------------------------+------------------------------ Comment (by parcs): Looks like GHC itself is broken when built with `BuildFlavour=prof`: {{{ ===--- building phase 0 make -r --no-print-directory -f ghc.mk phase=0 phase_0_builds make[1]: Nothing to be done for `phase_0_builds'. ===--- building phase 1 make -r --no-print-directory -f ghc.mk phase=1 phase_1_builds make[1]: Nothing to be done for `phase_1_builds'. ===--- building final phase make -r --no-print-directory -f ghc.mk phase=final all "inplace/bin/ghc-stage2" -hisuf hi -osuf o -hcsuf hc -static -H64m -O0 -fasm -package-name old-time-1.1.0.1 -hide-all-packages -i -ilibraries /old-time/. -ilibraries/old-time/dist-install/build -ilibraries/old-time /dist-install/build/autogen -Ilibraries/old-time/dist-install/build -Ilibraries/old-time/dist-install/build/autogen -Ilibraries/old- time/include -optP-include -optPlibraries/old-time/dist- install/build/autogen/cabal_macros.h -package base-4.7.0.0 -package old- locale-1.0.0.5 -XHaskell98 -XCPP -XForeignFunctionInterface -O -fasm -no- user-package-db -rtsopts -odir libraries/old-time/dist-install/build -hidir libraries/old-time/dist-install/build -stubdir libraries/old-time /dist-install/build -dynamic-too -c libraries/old-time/dist- install/build/System/Time.hs -o libraries/old-time/dist- install/build/System/Time.o -dyno libraries/old-time/dist- install/build/System/Time.dyn_o Segmentation fault make[1]: *** [libraries/old-time/dist-install/build/System/Time.o] Error 139 make: *** [all] Error 2 }}} -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/7978#comment:10> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

[GHC] #8104: By default GHC API looks for .dyn_o but only creates .o
by GHC 30 Jul '13

30 Jul '13

#8104: By default GHC API looks for .dyn_o but only creates .o ------------------------------------+------------------------------------- Reporter: edsko | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.6.3 Keywords: | Operating System: Unknown/Multiple Architecture: Unknown/Multiple | Type of failure: None/Unknown Difficulty: Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | ------------------------------------+------------------------------------- See the example program for http://ghc.haskell.org/trac/ghc/ticket/7918 . If we change {{{ dynFlags <- getSessionDynFlags void $ setSessionDynFlags (doDynamicToo dynFlags) }}} to {{{ dynFlags <- getSessionDynFlags void $ setSessionDynFlags dynFlags }}} so that we get the default `DynFlags`, the program fails. The program loads two modules A and B, and tries to typecheck B. B uses a quasi-quoter defined in A. With the default `DynFlags` it will fail with {{{ cannot find normal object file ‛./T7918A.dyn_o’ while linking an interpreted expression }}} i.e., it is looking for the `.dyn_o` file but only creates the `.o` file. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/8104> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 3

Re: [GHC] #3649: inconsistent exception between unix/windows for running non-existant program
by GHC 30 Jul '13

30 Jul '13

#3649: inconsistent exception between unix/windows for running non-existant program --------------------------------------+------------------------------------ Reporter: duncan | Owner: Type: bug | Status: closed Priority: low | Milestone: 7.6.2 Component: libraries/process | Version: 6.10.4 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 igloo): * status: new => closed * resolution: => fixed Comment: Looks like it; this now prints `True` on Linux: {{{ import Control.Exception import System.IO.Error import System.Process main = handle (print . isDoesNotExistError) $ do (_,_,_,hnd) <- createProcess (proc "foobar" []) print =<< waitForProcess hnd }}} Thanks for pointing it out, benmachine! -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/3649#comment:9> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

Re: [GHC] #5902: Cannot tell from an exception handler whether the exception was asynchronous
by GHC 30 Jul '13

30 Jul '13

#5902: Cannot tell from an exception handler whether the exception was asynchronous -------------------------------------+------------------------------------ Reporter: simonmar | Owner: simonmar Type: bug | Status: new Priority: high | Milestone: 7.8.1 Component: Compiler | Version: 7.4.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: None/Unknown | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: -------------------------------------+------------------------------------ Changes (by exbb2): * priority: normal => high Comment: If a type-based solution is implemented, I propose for SomeException to be deprecated and split into SomeSyncException and SomeAsyncException. Right now, SomeException and lack of discrimination for asynchronous exceptions pose serious threat to modularity in concurrent applications. Every innocuous catch or try anywhere at any time in any library can make a thread unintentionally uncancelable. I had to write patches for three different libraries because of this recurring problem; what would happen if my project depended on 50 libraries all throwing and catching exceptions? -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/5902#comment:18> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

Re: [GHC] #7918: SrcSpan's associated with expanded quasi-quotes are inconsistent
by GHC 30 Jul '13

30 Jul '13

#7918: SrcSpan's associated with expanded quasi-quotes are inconsistent -------------------------------------+------------------------------------ Reporter: edsko | Owner: Type: bug | Status: infoneeded Priority: normal | Milestone: Component: Compiler | Version: 7.4.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: None/Unknown | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: -------------------------------------+------------------------------------ Comment (by edsko): As demonstrated by the attached example, the problem still persists in GHC HEAD. The output of the program is {{{ Found HsVar GHC.Types.False at T7918B.hs:7:7-13 Found HsVar GHC.Types.True at T7918B.hs:6:11-13 Found HsVar GHC.Classes.|| at T7918B.hs:6:11-13 Found HsVar GHC.Types.False at T7918B.hs:6:11-13 Found HsVar GHC.Types.True at T7918B.hs:6:11-13 Found HsVar GHC.Classes.|| at T7918B.hs:6:11-13 Found HsVar GHC.Types.False at T7918B.hs:6:11-13 Found HsVar GHC.Types.True at T7918B.hs:6:11-13 Found HsVar GHC.Classes.|| at T7918B.hs:6:11-13 Found HsVar GHC.Types.False at T7918B.hs:6:11-13 Found HsVar GHC.Types.True at T7918B.hs:6:11-13 Found HsVar GHC.Classes.|| at T7918B.hs:6:11-13 Found HsVar GHC.Types.False at T7918B.hs:6:11-13 Found HsVar GHC.Types.True at T7918B.hs:5:11-13 Found HsVar GHC.Types.True at T7918B.hs:5:11-13 Found HsVar GHC.Types.True at T7918B.hs:4:7-13 }}} Note the 7-13 rather than 11-13 in the first and last line. Note that this is the source span associated with the HsVar, not with the larger expression (which is, indeed, consistent across the 4 quasi-quotes). I will try and see if I can come up with a patch for this. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/7918#comment:2> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

Re: [GHC] #4385: Type-level natural numbers
by GHC 30 Jul '13

30 Jul '13

#4385: Type-level natural numbers --------------------------------------------+------------------------------ Reporter: diatchki | Owner: diatchki Type: feature request | Status: new Priority: normal | Milestone: 7.6.2 Component: Compiler (Type checker) | Version: Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: None/Unknown | Unknown/Multiple Test Case: | Difficulty: Unknown Blocking: | Blocked By: | Related Tickets: --------------------------------------------+------------------------------ Changes (by norm2782): * cc: j.stutterheim@… (added) * difficulty: => Unknown -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/4385#comment:63> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

Re: [GHC] #3649: inconsistent exception between unix/windows for running non-existant program
by GHC 29 Jul '13

29 Jul '13

#3649: inconsistent exception between unix/windows for running non-existant program --------------------------------------+------------------------------------ Reporter: duncan | Owner: Type: bug | Status: new Priority: low | Milestone: 7.6.2 Component: libraries/process | Version: 6.10.4 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: None/Unknown | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: --------------------------------------+------------------------------------ Changes (by benmachine): * difficulty: => Unknown Comment: Since Ian's changes to libraries/process in commit df810a59d84703ca7ad548f29f635bda6f48b493 , is this fixed? -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/3649#comment:8> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

Re: [GHC] #3333: GHCi doesn't load weak symbols
by GHC 29 Jul '13

29 Jul '13

#3333: GHCi doesn't load weak symbols ---------------------------------+----------------------------------------- Reporter: heatsink | Owner: Type: bug | Status: new Priority: normal | Milestone: 7.6.2 Component: GHCi | Version: 6.10.4 Resolution: | Keywords: weak, dynamic loading Operating System: Linux | Architecture: x86 Type of failure: None/Unknown | Difficulty: Unknown Test Case: | Blocked By: 3658 Blocking: | Related Tickets: ---------------------------------+----------------------------------------- Comment (by slyfox): Replying to [comment:29 igloo]: > Replying to [comment:26 akio]: > > Replying to [comment:24 igloo]: > > Why is this blocked by #3658? Isn't the ability to load a static C++ object file independent to the ability to use the system linker? > > We could fix it in our own linker, but I think it would be a waste of effort when we're removing our linker and using the system linker instead. > > In HEAD we're already using the system linker on Elf platforms by default (except for FreeBSD, due to a bug in their system linker, but even there we will switch to the system linker once 7.8 is branched). What do you think of including at least 0001-Test-Trac-3333.patch to the test suite? -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/3333#comment:30> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

Re: [GHC] #6135: Unboxed Booleans
by GHC 29 Jul '13

29 Jul '13

#6135: Unboxed Booleans -------------------------------------+------------------------------------ Reporter: benl | Owner: jstolarek Type: feature request | Status: new Priority: normal | Milestone: 7.8.1 Component: Compiler | Version: 7.4.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: None/Unknown | Difficulty: Unknown Test Case: | Blocked By: #8103 Blocking: | Related Tickets: #605 -------------------------------------+------------------------------------ Changes (by jstolarek): * owner: => jstolarek -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/6135#comment:80> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0