- ghc-tickets - Haskell.org

[GHC] #8028: Panic on degenerate closed type family
by GHC 02 Jul '13

02 Jul '13

#8028: Panic on degenerate closed type family ----------------------------------------------+----------------------------- Reporter: monoidal | Owner: Type: bug | Status: new Priority: normal | Component: Compiler (Type checker) Version: 7.7 | Keywords: Os: Unknown/Multiple | Architecture: Unknown/Multiple Failure: Incorrect warning at compile-time | Blockedby: Blocking: | Related: ----------------------------------------------+----------------------------- Creating a degenerate closed type family via TH gives a panic in `toBranchList`. {{{ module T where import Language.Haskell.TH x = do n <- newName "F" return [ClosedTypeFamilyD n [] Nothing []] }}} {{{ module A where import T $(x) }}} -- Ticket URL: <http://hackage.haskell.org/trac/ghc/ticket/8028> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 3

[GHC] #7970: Thread GC frees roots before thread actually finishes
by GHC 02 Jul '13

02 Jul '13

#7970: Thread GC frees roots before thread actually finishes -----------------------------+---------------------------------------------- Reporter: joeyadams | Owner: Type: bug | Status: new Priority: normal | Component: Runtime System Version: 7.6.3 | Keywords: Os: Unknown/Multiple | Architecture: Unknown/Multiple Failure: Runtime crash | Blockedby: Blocking: | Related: 7170 -----------------------------+---------------------------------------------- In the following program, an IORef is garbage collected after a `NonTermination` exception, but is subsequently accessed: {{{ import Control.Exception as E import Data.IORef import System.Mem.Weak main :: IO () main = do ref <- newIORef 'x' weak <- mkWeakIORef ref $ putStrLn "IORef finalized" let check = deRefWeak weak >>= \m -> case m of Nothing -> putStrLn "IORef was GCed" Just ref' -> do x <- readIORef ref' putStrLn $ "IORef still alive, and contains " ++ show x let loop = loop check loop `catch` \ex -> do putStrLn $ "caught exception: " ++ show (ex :: SomeException) check readIORef ref >>= print }}} Output: {{{ IORef still alive, and contains 'x' IORef finalized caught exception: <<loop>> IORef was GCed 'x' }}} The same happens with other thread deadlocks, such as: * newEmptyMVar >>= takeMVar * atomically retry It does not happen when a `StackOverflow` or `UserInterrupt` exception is caught. This also affects `ForeignPtr`; see the attached "database" example. This is what really triggered #7170. I marked this "Runtime crash" because it can lead to a `ForeignPtr` being accessed after the garbage collector finalized it. -- Ticket URL: <http://hackage.haskell.org/trac/ghc/ticket/7970> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 9

[GHC] #8022: Outdated documentation for the -fwarn-lazy-unlifted-bindings warning
by GHC 02 Jul '13

02 Jul '13

#8022: Outdated documentation for the -fwarn-lazy-unlifted-bindings warning -----------------------------+---------------------------------------------- Reporter: asr | Owner: Type: bug | Status: new Priority: normal | Component: Documentation Version: 7.6.3 | Keywords: Os: Unknown/Multiple | Architecture: Unknown/Multiple Failure: None/Unknown | Blockedby: Blocking: | Related: -----------------------------+---------------------------------------------- The section 4.8 of 'The Glorious Glasgow Haskell Compilation System User's Guide, Version 7.6.3' says: {{{-fwarn-lazy-unlifted-bindings:}}} ... This will be an error, rather than a warning, in GHC 7.2. I guess the above sentence should be removed. -- Ticket URL: <http://hackage.haskell.org/trac/ghc/ticket/8022> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 1

[GHC] #7979: ./configure script does not properly detect missing header files
by GHC 02 Jul '13

02 Jul '13

#7979: ./configure script does not properly detect missing header files -----------------------------+---------------------------------------------- Reporter: jstolarek | Owner: Type: bug | Status: new Priority: normal | Component: Build System Version: 7.6.3 | Keywords: Os: Unknown/Multiple | Architecture: Unknown/Multiple Failure: None/Unknown | Blockedby: Blocking: | Related: -----------------------------+---------------------------------------------- I was trying to compile GHC on a fresh installation of Debian Wheezy and I got this compilation error: {{{ CROSS_COMPILE="" "inplace/bin/ghc-cabal" configure --with-ghc="/dane/download/ghc-7.6.3/inplace/bin/ghc-stage1" --with-ghc-pkg="[9/1856] wnload/ghc-7.6.3/inplace/bin/ghc-pkg" --enable-library-profiling --enable-shared --enable-library-for-ghci --configure-option=CFLAGS=" -fno-stack-protector " --configure-option=LDFLAGS=" -Wl,--hash-size=31 -Wl,--reduce-memory-overheads " --configure-option=CPPFLAGS=" " --with-gcc="/usr/bin/gcc" --configure-option=--with-cc="/usr/bin/gcc" --with-ar="/usr/bin/ar" --with-ranlib="true" --with-alex="/usr /bin/alex" --with-happy="/usr/bin/happy" -- dist-install libraries/terminfo Configuring terminfo-0.3.2.4... configure: WARNING: unrecognized options: --with-compiler, --with-gcc checking for gcc... /usr/bin/gcc checking whether the C compiler works... yes checking for C compiler default output file name... a.out checking for suffix of executables... checking whether we are cross compiling... no checking for suffix of object files... o checking whether we are using the GNU C compiler... yes checking whether /usr/bin/gcc accepts -g... yes checking for /usr/bin/gcc option to accept ISO C89... none needed checking how to run the C preprocessor... /usr/bin/gcc -E checking for grep that handles long lines and -e... /bin/grep checking for egrep... /bin/grep -E checking for ANSI C header files... yes checking for sys/types.h... yes checking for sys/stat.h... yes checking for stdlib.h... yes checking for string.h... yes checking for memory.h... yes checking for strings.h... yes checking for inttypes.h... yes checking for stdint.h... yes checking for unistd.h... yes checking ncurses.h usability... no checking ncurses.h presence... no checking for ncurses.h... no checking curses.h usability... no checking curses.h presence... no checking for curses.h... no configure: error: in `/dane/download/ghc-7.6.3/libraries/terminfo': configure: error: curses headers could not be found, so this package cannot be built See `config.log' for more details make[1]: *** [libraries/terminfo/dist-install/package-data.mk] Error 1 make: *** [all] Error 2 }}} Which means that `./configure` did not detect that ncurses header files are missing from the system. I think that in this situation `./configure` should fail and inform the user that required header files are missing. Also, I noticed that when Alex and Happy are missing from the system then `./configure` will also not complain. I admit I didn't try to build with these two binaries missing, but I suspect that building would fail. If so, then `./configure` script should also fail in this situation. -- Ticket URL: <http://hackage.haskell.org/trac/ghc/ticket/7979> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 8

Re: [GHC] #551: "No threads to run" ignores finalizers
by GHC 02 Jul '13

02 Jul '13

#551: "No threads to run" ignores finalizers -----------------------------+---------------------------------------------- Reporter: chak | Owner: simonmar Type: bug | Status: closed Priority: normal | Milestone: Component: Runtime System | Version: 5.0 Resolution: Fixed | Keywords: -----------------------------+---------------------------------------------- Comment(by marlowsd@…): commit 1ae72ac45e51e63cbf6f3d627d77acc6a36aa0f9 {{{ Author: Simon Marlow <marlowsd(a)gmail.com> Date: Tue Jul 2 12:10:53 2013 +0100 Fix #7970, #2161, unfix #551 Establish the reachability of threads before weak pointers. Hence a deadlocked thread can keep a weak pointer alive and prevent it from being finalized early. However, an reference from the finalizer of a weak pointer will no longer prevent a thread from being considered deadlocked (#551). To keep the thread alive in that situation you need to use a StablePtr. See comments on #7970 and in the code for more details. rts/sm/MarkWeak.c | 100 +++++++++++++++++++++++++++------------------------- 1 files changed, 52 insertions(+), 48 deletions(-) }}} -- Ticket URL: <http://hackage.haskell.org/trac/ghc/ticket/551#comment:5> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

Re: [GHC] #2161: finaliser of a ForeignPtr called while references from unreachable threads exist
by GHC 02 Jul '13

02 Jul '13

#2161: finaliser of a ForeignPtr called while references from unreachable threads exist ------------------------------------------+--------------------------------- Reporter: agl | Owner: Type: bug | Status: closed Priority: low | Milestone: 7.6.2 Component: Runtime System | Version: 6.8.2 Resolution: duplicate | Keywords: Os: Unknown/Multiple | Architecture: Unknown/Multiple Failure: Incorrect result at runtime | Difficulty: Unknown Testcase: | Blockedby: Blocking: | Related: ------------------------------------------+--------------------------------- Comment(by marlowsd@…): commit 1ae72ac45e51e63cbf6f3d627d77acc6a36aa0f9 {{{ Author: Simon Marlow <marlowsd(a)gmail.com> Date: Tue Jul 2 12:10:53 2013 +0100 Fix #7970, #2161, unfix #551 Establish the reachability of threads before weak pointers. Hence a deadlocked thread can keep a weak pointer alive and prevent it from being finalized early. However, an reference from the finalizer of a weak pointer will no longer prevent a thread from being considered deadlocked (#551). To keep the thread alive in that situation you need to use a StablePtr. See comments on #7970 and in the code for more details. rts/sm/MarkWeak.c | 100 +++++++++++++++++++++++++++------------------------- 1 files changed, 52 insertions(+), 48 deletions(-) }}} -- Ticket URL: <http://hackage.haskell.org/trac/ghc/ticket/2161#comment:11> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

Re: [GHC] #2161: finaliser of a ForeignPtr called while references from unreachable threads exist
by GHC 02 Jul '13

02 Jul '13

#2161: finaliser of a ForeignPtr called while references from unreachable threads exist ------------------------------------------+--------------------------------- Reporter: agl | Owner: Type: bug | Status: closed Priority: low | Milestone: 7.6.2 Component: Runtime System | Version: 6.8.2 Resolution: duplicate | Keywords: Os: Unknown/Multiple | Architecture: Unknown/Multiple Failure: Incorrect result at runtime | Difficulty: Unknown Testcase: | Blockedby: Blocking: | Related: ------------------------------------------+--------------------------------- Changes (by simonmar): * status: new => closed * resolution: => duplicate Comment: Closing in favour of #7970 -- Ticket URL: <http://hackage.haskell.org/trac/ghc/ticket/2161#comment:10> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

[GHC] #7830: Error: operand out of range
by GHC 02 Jul '13

02 Jul '13

#7830: Error: operand out of range ----------------------------------+----------------------------------------- Reporter: erikd | Owner: Type: bug | Status: new Priority: normal | Component: Compiler Version: 7.7 | Keywords: Os: Linux | Architecture: powerpc Failure: Installing GHC failed | Blockedby: Blocking: | Related: ----------------------------------+----------------------------------------- Compiling on linux-powerpc and linux-powerpc64 I get: {{{ "inplace/bin/ghc-stage1" -hisuf hi -osuf o -hcsuf hc -static -H32m -O -Werror -Wall \ -H64m -O0 -package-name time-1.4.0.2 -hide-all-packages -i -ilibraries/time/. \ -ilibraries/time/dist-install/build -ilibraries/time/dist- install/build/autogen \ -Ilibraries/time/dist-install/build -Ilibraries/time/dist- install/build/autogen \ -Ilibraries/time/include -optP-DLANGUAGE_Rank2Types -optP \ DLANGUAGE_DeriveDataTypeable -optP-DLANGUAGE_StandaloneDeriving -optP- include \ -optPlibraries/time/dist-install/build/autogen/cabal_macros.h -package base-4.7.0.0 \ -package deepseq-1.3.0.2 -package old-locale-1.0.0.5 -Wall -XHaskell2010 -XRank2Types \ -XDeriveDataTypeable -XStandaloneDeriving -XCPP -O2 -O -dcore-lint \ -fno-warndeprecated-flags -no-user-package-db -rtsopts -fno-warn- unused-do-bind \ -fno-warn-deprecations -fno-warn-unused-imports -fno-warn-identities -odir \ libraries/time/dist-install/build -hidir libraries/time/dist- install/build -stubdir \ libraries/time/dist-install/build -dynamic-too -c libraries/time/./Data/Time/Format.hs \ -o libraries/time/dist-install/build/Data/Time/Format.o -dyno \ libraries/time/dist-install/build/Data/Time/Format.dyn_o /tmp/ghc2806_0/ghc2806_1.s: Assembler messages: /tmp/ghc2806_0/ghc2806_1.s:51766:0: Error: operand out of range (0x000000000000adf8 is not between 0xffffffffffff8000 and 0x0000000000007fff) /tmp/ghc2806_0/ghc2806_1.s:51798:0: Error: operand out of range (0x000000000000ad90 is not between 0xffffffffffff8000 and 0x0000000000007fff) /tmp/ghc2806_0/ghc2806_1.s:51830:0: Error: operand out of range (0x000000000000ad28 is not between 0xffffffffffff8000 and 0x0000000000007fff) /tmp/ghc2806_0/ghc2806_1.s:51908:0: Error: operand out of range (0x000000000000ac1c is not between 0xffffffffffff8000 and 0x0000000000007fff) }}} -- Ticket URL: <http://hackage.haskell.org/trac/ghc/ticket/7830> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

2 11

[GHC] #8025: "During interactive linking, GHCi couldn't find the following symbol" typechecker error with TemplateHaskell involved
by GHC 30 Jun '13

30 Jun '13

#8025: "During interactive linking, GHCi couldn't find the following symbol" typechecker error with TemplateHaskell involved ----------------------------------------------+----------------------------- Reporter: mojojojo | Owner: Type: bug | Status: new Priority: normal | Component: Compiler (Type checker) Version: 7.6.3 | Keywords: Os: MacOS X | Architecture: x86 Failure: Incorrect warning at compile-time | Blockedby: Blocking: | Related: ----------------------------------------------+----------------------------- Building the included project with {{{ cabal configure && cabal build --ghc-options="-fforce-recomp -Wall -fno- code" }}} results in the following typechecker error: {{{ ByteCodeLink.lookupCE During interactive linking, GHCi couldn't find the following symbol: supabugzm0zi1zi0_A_makeLenseszq_closure This may be due to you not asking GHCi to load extra object files, archives or DLLs needed by your current session. Restart GHCi, specifying the missing library using the -L/path/to/object/dir and -lmissinglibname flags, or simply by naming the relevant files on the GHCi command line. Alternatively, this link failure might indicate a bug in GHCi. If you suspect the latter, please send a bug report to: glasgow-haskell-bugs(a)haskell.org }}} -- Ticket URL: <http://hackage.haskell.org/trac/ghc/ticket/8025> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

[GHC] #8024: Illegal instruction in cr_str
by GHC 30 Jun '13

30 Jun '13

#8024: Illegal instruction in cr_str --------------------------------+------------------------------------------- Reporter: erikd | Owner: Type: bug | Status: new Priority: normal | Component: Compiler Version: 7.7 | Keywords: Os: Linux | Architecture: powerpc Failure: Building GHC failed | Blockedby: Blocking: | Related: --------------------------------+------------------------------------------- During the process of coming up for a fix for ticket #7830 (which left GHC un-buildable for many months) I ran into this problem. After coming up with a fix for #7830 I ran into this problem where the first executable (compiled with the stage1 compiler) to run crashes with an illegal instruction: {{{ (gdb) bt #0 0x0f3f2e24 in cr_str () from /home/erikd/Git/ghc- upstream/rts/dist/build/libHSrts-ghc7.7.20130630.so #1 0x0f3de490 in stg_catchzh () from /home/erikd/Git/ghc- upstream/rts/dist/build/libHSrts-ghc7.7.20130630.so #2 0x0f3cc01c in scheduleWaitThread () from /home/erikd/Git/ghc- upstream/rts/dist/build/libHSrts-ghc7.7.20130630.so #3 0x0f3c63dc in rts_evalLazyIO () from /home/erikd/Git/ghc- upstream/rts/dist/build/libHSrts-ghc7.7.20130630.so #4 0x0f3c8300 in hs_main () from /home/erikd/Git/ghc- upstream/rts/dist/build/libHSrts-ghc7.7.20130630.so #5 0x10006ae4 in main () }}} Disassmbling the function gives: {{{ Dump of assembler code for function cr_str: 0x0f3f2dec: rlwimi r1,r2,10,0,16 0x0f3f2df0: xoris r2,r27,27237 0x0f3f2df4: ori r20,r27,8293 0x0f3f2df8: xoris r20,r19,25970 0x0f3f2dfc: oris r4,r11,8448 0x0f3f2e00: .long 0xfffeae2c 0x0f3f2e04: .long 0xfffeae2c 0x0f3f2e08: .long 0xfffeae2c 0x0f3f2e0c: .long 0xfffeae2c 0x0f3f2e10: .long 0xfffeae2c 0x0f3f2e14: .long 0xfffeae2c 0x0f3f2e18: .long 0xfffeae2c 0x0f3f2e1c: .long 0xfffeae2c 0x0f3f2e20: .long 0xfffeae2c => 0x0f3f2e24: .long 0xfffeae20 0x0f3f2e28: .long 0xfffeae20 0x0f3f2e2c: .long 0xfffeae20 0x0f3f2e30: .long 0xfffeae20 }}} However function stg_catchzh() in rts/Exception.cmm does not call cr_str(). -- Ticket URL: <http://hackage.haskell.org/trac/ghc/ticket/8024> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 1