April 2014 - ghc-tickets

[GHC] #9021: rts/linker.c has a memory leak in the dlopen/dlerror code
by GHC 03 Jun '14

03 Jun '14

#9021: rts/linker.c has a memory leak in the dlopen/dlerror code -------------------------------------+------------------------------------- Reporter: hgolden | Owner: hgolden Type: bug | Status: new Priority: low | Milestone: 7.8.3 Component: Runtime System | Version: 7.8.2 Keywords: linker, memory | Operating System: POSIX leak | Type of failure: Runtime Architecture: Unknown/Multiple | performance bug Difficulty: Moderate (less | Test Case: than a day) | Blocking: Blocked By: | Related Tickets: | -------------------------------------+------------------------------------- The Coverity Scan of ghc highlighted a memory leak (CID 43168) in the internal_dlopen function in rts/linker.c. I wrote this code originally and I recall that there was a memory leak in certain situations, but I didn't fix it at the time because it seemed to be rather minor and only would occur in unusual cases. However, since Coverity identified it, I have thought about it and know how to fix the leak, so I am creating this ticket. The leak occurs because the error message from dlerror must be copied to allocated memory, since the dlerror message is not guaranteed to be stable, and its code is not guaranteed to be reentrant (see POSIX dlopen/dlerror documentation). As I originally coded Trac ticket #2615, I didn't bother to free the allocated memory. The fix is to make sure that the allocated memory is freed once the error message is displayed. Memory is only allocated if there is an error, so it must be freed only when an error has been identified and processed. As far as I know, this bug only exists on a POSIX system. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/9021> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 8

[GHC] #8197: telling people how to use GHC 7.6 correctly with Xcode 5/ OS X Mavericks
by GHC 24 May '14

24 May '14

#8197: telling people how to use GHC 7.6 correctly with Xcode 5/ OS X Mavericks ----------------------------------+--------------------------------- Reporter: carter | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.6.3 Keywords: | Operating System: MacOS X Architecture: x86_64 (amd64) | Type of failure: None/Unknown Difficulty: Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | ----------------------------------+--------------------------------- Are we going to make available directions so that people can use 7.6 correctly with xcode 5 and/or mavericks? eg: will we provide directions to either 1. use Luke Ianni's clang wrapper hack, and bundle that with a 7.6 release thats 7.6.3 + that extra binary to make a 10.8 friendly "stability" release 2. tell people to stick to xcode 4.6 and/or install a newer GCC (say, GCC 4.8) and adjust their ghc settings file to point to that other GCC? We need to provide this information in a clear way, because this WILL be a problem where we'll have a support load from it (whether we want to or not, until GHC 7.8 gets a haskell platform release, this WILL happen. We need to have a mitigation strategy so that we aren't dealing with it constantly) -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/8197> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 9

[GHC] #9045: threads006: internal error: scavenge_stack: weird activation record found on stack: 415597384
by GHC 21 May '14

21 May '14

#9045: threads006: internal error: scavenge_stack: weird activation record found on stack: 415597384 ------------------------------------+------------------------------------- Reporter: simonmar | Owner: simonmar Type: bug | Status: new Priority: highest | Milestone: 7.8.3 Component: Runtime System | Version: 7.8.2 Keywords: | Operating System: Unknown/Multiple Architecture: Unknown/Multiple | Type of failure: Runtime crash Difficulty: Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #8866 | ------------------------------------+------------------------------------- Found this while working on something else. This is a real bug that can cause random `scavenge_stack` failures at runtime, and could be the cause of #8866. I have a fix on the way... -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/9045> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 5

[GHC] #9016: Add System.Exit.die
by GHC 20 May '14

20 May '14

#9016: Add System.Exit.die ------------------------------------+------------------------------------- Reporter: SimonHengel | Owner: Type: feature request | 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: | ------------------------------------+------------------------------------- (as per the proposal/discussion on haskell-libraries, I just posted a summary that "awaits moderator approval") -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/9016> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 14

[GHC] #9035: ghci sometimes displays Word32 as Word64
by GHC 19 May '14

19 May '14

#9035: ghci sometimes displays Word32 as Word64 --------------------------+------------------------------------------------ Reporter: | Owner: MikeIzbicki | Status: new Type: bug | Milestone: Priority: normal | Version: 7.8.2 Component: GHCi | Operating System: Linux Keywords: | Type of failure: Incorrect result at runtime Architecture: x86_64 | Test Case: (amd64) | Blocking: Difficulty: | Unknown | Blocked By: | Related Tickets: | --------------------------+------------------------------------------------ Given this code: {{{ module Main where import Data.Word import Unsafe.Coerce import System.IO nanFloat :: Float nanFloat = unsafeCoerce (maxBound :: Word32) float2word32 :: Float -> Word32 float2word32 = unsafeCoerce nanDouble :: Double nanDouble = unsafeCoerce (maxBound :: Word64) double2word64 :: Double -> Word64 double2word64 = unsafeCoerce main = do putStrLn $ "nanFloat = " ++ show (float2word32 nanFloat) putStrLn $ "nanFloat = " ++ show (float2word32 $ nanFloat + 1) putStrLn $ "nanDouble = " ++ show (double2word64 nanDouble) putStrLn $ "nanDouble = " ++ show (double2word64 $ nanDouble + 1) }}} If we compile with GHC and run, we correctly output: {{{ nanFloat = 4294967295 nanFloat = 4294967295 nanDouble = 18446744073709551615 nanDouble = 18446744073709551615 }}} But if we instead load in ghci, we get the following output: {{{ nanFloat = 4294967295 nanFloat = 140247862083583 nanDouble = 18446744073709551615 nanDouble = 18446744073709551615 }}} For some reason, ghci is displaying (nanFloat+1) as having significantly more digits than can possibly stored in a Word32 value. Test system: Intel Core 2 Duo running Debian with GHC 7.8.2 -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/9035> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 6

[GHC] #8673: GHC could generate GADT record selectors in more cases
by GHC 17 May '14

17 May '14

#8673: GHC could generate GADT record selectors in more cases ------------------------------------+------------------------------------- Reporter: simonpj | Owner: Type: feature request | 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: | ------------------------------------+------------------------------------- Philip Holzenspies writes (in email to ghc-users): I was playing around with GADT-records again and ran into behaviour that I'm not sure is intentional. Given this program: {{{ {-#LANGUAGE GADTs #-} data FooBar x a where Foo :: { fooBar :: a } -> FooBar Char a Bar :: { fooBar :: a } -> FooBar Bool a }}} GHC tells me this: {{{ foo.hs:3:1: Constructors Foo and Bar have a common field `fooBar', but have different result types In the data declaration for `FooBar' Failed, modules loaded: none. }}} The user guide does say (section 7.4.7): "However, for GADTs there is the following additional constraint: every constructor that has a field f must have the same result type (modulo alpha conversion)." So this behaviour is documented in the user guide. However, it seems reasonable that in the case above, where all the relevant variables are exposed in the result type of both constructors, this should be perfectly typeable. In other words, shouldn't GHC be able to derive a type that is simply: {{{ fooBar :: FooBar x a -> a }}} ? Is this something that was simply never implemented, but could be, or is this not decidable or prohibitively computationally complex? -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/8673> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 2

[GHC] #8991: HLint: Illegal instruction (core dumped)
by GHC 14 May '14

14 May '14

#8991: HLint: Illegal instruction (core dumped) ----------------------------------+------------------------------------- Reporter: tensor5 | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.8.1 Keywords: | Operating System: Unknown/Multiple Architecture: x86_64 (amd64) | Type of failure: None/Unknown Difficulty: Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | ----------------------------------+------------------------------------- After upgrading to 7.8.1 output of {{{hlint}}} is {{{Illegal instruction (core dumped)}}} on any file that I tested. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/8991> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 7

[GHC] #9055: unregisterised build fails with: globalRegMaybe not defined for this platform
by GHC 13 May '14

13 May '14

#9055: unregisterised build fails with: globalRegMaybe not defined for this platform -----------------------------------+--------------------------------------- Reporter: trommler | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.9 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: Compile-time crash Unknown/Multiple | Test Case: Difficulty: Unknown | Blocking: Blocked By: | Related Tickets: | -----------------------------------+--------------------------------------- Building HEAD fails with: {{{ make[1]: *** [rts/dist/build/Updates.o] Error 1 ghc-stage1: panic! (the 'impossible' happened) (GHC version 7.9.20140429 for powerpc64-unknown-linux): globalRegMaybe not defined for this platform }}} on Linux powerpc64 and x86_64 (unregisterised). -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/9055> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 7

[GHC] #8935: Obscure linker bug leads to crash in GHCi
by GHC 02 May '14

02 May '14

#8935: Obscure linker bug leads to crash in GHCi ------------------------------------+------------------------------------- Reporter: simonmar | Owner: simonmar Type: bug | Status: new Priority: high | Milestone: 7.8.2 Component: Runtime System | Version: 7.6.3 Keywords: | Operating System: Unknown/Multiple Architecture: Unknown/Multiple | Type of failure: GHCi crash Difficulty: Rocket Science | Test Case: Blocked By: | Blocking: Related Tickets: | ------------------------------------+------------------------------------- I have a build of GHC (with `DYNAMIC_GHC_PROGRAMS=NO`) that exhibits the following crash: {{{ $ ghc -e 'System.Environment.getEnvironment' <segfault> }}} I tracked it down, eventually, to a bad reference to the symbol `environ` from `__hscore_environ` in `libraries/base/includes/HsBase.h`. Somehow, `environ` had got linked to the wrong address. Lots more investigation lead me to discover this: `internal_dlsym()` in `Linker.c` tries to look up a symbol in all the different shared libraries we have loaded so far, one by one. (see be497c202b790999c3fd0ddc4a4176b8cf6acf7e). Unfortunately, this seems to break things in my case. Here's a simple test program that works on Ubuntu 12.04: {{{ #include <dlfcn.h> #include <stdio.h> char *so = "/usr/lib/x86_64-linux-gnu/libgmp.so"; char *so2 = "/usr/lib/x86_64-linux-gnu/libpthread.so"; extern char**environ; int main(int argc, char *argv[]) { void *deflt, *hdl; deflt = dlopen(NULL, RTLD_LAZY | RTLD_GLOBAL); printf("environ = %p\n", &environ); printf("dlsym(deflt, \"environ\") = %p\n", dlsym(deflt,"environ")); hdl = dlopen(so, RTLD_LAZY); printf("dlsym(\"libgmp\", \"environ\") = %p\n", dlsym(hdl,"environ")); hdl = dlopen(so2, RTLD_LAZY); printf("dlsym(\"libpthread\", \"environ\") = %p\n", dlsym(hdl,"environ")); } }}} And the output: {{{ environ = 0x601040 dlsym(deflt, "environ") = 0x601040 dlsym("libgmp", "environ") = 0x2aaaab290568 dlsym("libpthread", "environ") = 0x601040 }}} Note that the value we get from looking up `environ` in `libgmp` is different to the others. The correct value is `0x601040`. gdb thinks that `0x2aaaab290568` is also `environ`: {{{ (gdb) p4 0x2aaaab290568 0x2aaaab290580 <buflen.9817>: 0x0 0x2aaaab290578: 0x0 0x2aaaab290570 <miss_F_GETOWN_EX>: 0x0 0x2aaaab290568 <environ>: 0x0 }}} but note that it contains zero. The real one is: {{{ (gdb) p4 0x601040 0x601058: 0x0 0x601050 <dtor_idx.6533>: 0x0 0x601048 <completed.6531>: 0x0 0x601040 <environ@@GLIBC_2.2.5>: 0x7fffffffe268 }}} In GHC we're loading `libgmp` when we load the `integer-gmp` package, and this causes future references to `environ` to go wrong. I've locally fixed this by changing `internal_dlsym` to `dlsym`, but since there was a reason to make this change in the first place I haven't pushed it to master. Suggestions welcome. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/8935> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 64

[GHC] #8933: process007: internal error: checkStackFrame: weird activation record found on stack
by GHC 01 May '14

01 May '14

#8933: process007: internal error: checkStackFrame: weird activation record found on stack ------------------------------------+---------------------------------- Reporter: trommler | Owner: Type: bug | Status: new Priority: normal | Milestone: 7.8.1 Component: Compiler | Version: 7.8.1-rc2 Keywords: | Operating System: Linux Architecture: Unknown/Multiple | Type of failure: Runtime crash Difficulty: Unknown | Test Case: process007 Blocked By: | Blocking: Related Tickets: | ------------------------------------+---------------------------------- On an unregisterised compiler process007 segfaults in all WAYS. Here is a stack trace from a run with {{{+RTS -DS}}} on an x86_64 machine: {{{ Starting program: /home/trp/research/ghc- unreg/ghc-7.8/libraries/process/tests/process007 +RTS -DS [Thread debugging using libthread_db enabled] Using host libthread_db library "/lib64/libthread_db.so.1". cap 0: initialised process007: internal error: checkStackFrame: weird activation record found on stack (0x7ffff69050b8 281051976). (GHC version 7.8.0.20140324 for x86_64_unknown_linux) Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug Program received signal SIGABRT, Aborted. 0x00007ffff6a95849 in raise () from /lib64/libc.so.6 (gdb) where #0 0x00007ffff6a95849 in raise () from /lib64/libc.so.6 #1 0x00007ffff6a96cd8 in abort () from /lib64/libc.so.6 #2 0x00000000008172af in rtsFatalInternalErrorFn ( s=0x894080 "checkStackFrame: weird activation record found on stack (%p %d).", ap=0x7fffffffd968) at rts/RtsMessages.c:170 #3 0x0000000000816ee7 in barf ( s=0x894080 "checkStackFrame: weird activation record found on stack (%p %d).") at rts/RtsMessages.c:42 #4 0x00000000008355e2 in checkStackFrame (c=0x7ffff69050b8) at rts/sm/Sanity.c:165 #5 0x000000000083560a in checkStackChunk (sp=0x7ffff69050b8, stack_end=0x7ffff6905390) at rts/sm/Sanity.c:177 #6 0x0000000000836100 in checkSTACK (stack=0x7ffff6905000) at rts/sm/Sanity.c:497 #7 0x0000000000836254 in checkTSO (tso=0x7ffff6905390) at rts/sm/Sanity.c:535 #8 0x000000000082625a in threadStackOverflow (cap=0xd79740 <MainCapability>, tso=0x7ffff6905390) at rts/Threads.c:500 #9 0x000000000082226a in schedule ( initialCapability=0xd79740 <MainCapability>, task=0xd9a4e0) at rts/Schedule.c:528 #10 0x00000000008236b3 in scheduleWaitThread (tso=0x7ffff6905390, ret=0x0, pcap=0x7fffffffdcc0) at rts/Schedule.c:2346 #11 0x0000000000824d63 in rts_evalLazyIO (cap=0x7fffffffdcc0, p=0xbd4da0 <ZCMain_main_closure>, ret=0x0) at rts/RtsAPI.c:500 #12 0x00000000008272de in real_main () at rts/RtsMain.c:63 #13 0x00000000008273d1 in hs_main (argc=3, argv=0x7fffffffde48, main_closure=0xbd4da0 <ZCMain_main_closure>, rts_config=...) at rts/RtsMain.c:114 #14 0x000000000040849f in main () }}} Running without the RTS flags: {{{ Program received signal SIGSEGV, Segmentation fault. 0x00000000008307ed in StgRun (f=0xd79758b8e5894855, basereg=0xd79758 <MainCapability+24>) at rts/StgCRun.c:81 81 f = (StgFunPtr) (f)(); (gdb) where #0 0x00000000008307ed in StgRun (f=0xd79758b8e5894855, basereg=0xd79758 <MainCapability+24>) at rts/StgCRun.c:81 #1 0x0000000000822022 in schedule ( initialCapability=0xd79740 <MainCapability>, task=0xd9a470) at rts/Schedule.c:463 #2 0x00000000008236b3 in scheduleWaitThread (tso=0x7ffff6905390, ret=0x0, pcap=0x7fffffffdcd0) at rts/Schedule.c:2346 #3 0x0000000000824d63 in rts_evalLazyIO (cap=0x7fffffffdcd0, p=0xbd4da0 <ZCMain_main_closure>, ret=0x0) at rts/RtsAPI.c:500 #4 0x00000000008272de in real_main () at rts/RtsMain.c:63 #5 0x00000000008273d1 in hs_main (argc=1, argv=0x7fffffffde58, main_closure=0xbd4da0 <ZCMain_main_closure>, rts_config=...) at rts/RtsMain.c:114 #6 0x000000000040849f in main () }}} The value of f in StgRun looks strange the first three bytes are the same as basereg {{{0xd79758}}}. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/8933> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 7