August 2013 - ghc-tickets

Re: [GHC] #5188: Runtime error when allocating lots of memory
by GHC 26 Aug '13

26 Aug '13

#5188: Runtime error when allocating lots of memory ---------------------------------+--------------------------- Reporter: knyblad | Owner: Type: bug | Status: new Priority: low | Milestone: 7.6.2 Component: GHCi | Version: 6.12.1 Resolution: | Keywords: Operating System: Linux | Architecture: x86 Type of failure: None/Unknown | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: ---------------------------------+--------------------------- Comment (by rwbarton): So I investigated further with gdb, and while I no longer have the exact numbers, gmp was indeed asking for an allocation of more than 4095 MB, resulting in `osGetMBlocks(4096)` and an integer overflow when computing `size` resulting in `size = 0`. The fix should be to detect when the computation of `size` will overflow a `size_t`, and report an out-of-memory error if this occurs. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/5188#comment:7> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

Re: [GHC] #5144: Pattern synonyms
by GHC 26 Aug '13

26 Aug '13

#5144: Pattern synonyms -------------------------------------+------------------------------------ Reporter: simonpj | Owner: cactus Type: feature request | Status: new Priority: normal | Milestone: _|_ Component: Compiler | Version: 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 liyang): * cc: hackage.haskell.org@… (added) -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/5144#comment:32> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

Re: [GHC] #5188: Runtime error when allocating lots of memory
by GHC 25 Aug '13

25 Aug '13

#5188: Runtime error when allocating lots of memory ---------------------------------+--------------------------- Reporter: knyblad | Owner: Type: bug | Status: new Priority: low | Milestone: 7.6.2 Component: GHCi | Version: 6.12.1 Resolution: | Keywords: Operating System: Linux | Architecture: x86 Type of failure: None/Unknown | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: ---------------------------------+--------------------------- Changes (by rwbarton): * difficulty: => Unknown Comment: I was able to reproduce this (Linux 2.6.32-5-686, GHC 7.4.2). Here is the offending mmap call, from strace: `mmap2(0x8d900000, 0, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = -1 EINVAL (Invalid argument)` ... which is certainly invalid (from the mmap man page: "EINVAL (since Linux 2.6.12) length was 0.") I'll try to figure out why it is mmapping 0 bytes. Could be an integer overflow, when `size` is computed in `osGetMBlocks`... -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/5188#comment:6> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

Re: [GHC] #7500: GHC: internal error: getMBlock: mmap: Operation not permitted
by GHC 25 Aug '13

25 Aug '13

#7500: GHC: internal error: getMBlock: mmap: Operation not permitted ----------------------------------+------------------------------------ Reporter: guest | Owner: Type: bug | Status: new Priority: normal | Milestone: 7.8.1 Component: Compiler | Version: 7.4.1 Resolution: | Keywords: Operating System: Linux | Architecture: Unknown/Multiple Type of failure: Runtime crash | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: ----------------------------------+------------------------------------ Comment (by rwbarton): I was able to reproduce this on a 32-bit Linux system by setting `mmap_min_addr` to 2MB (`sudo /sbin/sysctl -w vm.mmap_min_addr=$((2*1048576))`). 1MB was not small enough. `mmap_min_addr` is a security measure that forbids a user program from mapping pages at or near address 0. (This eliminates an easy mechanism for exploiting kernel NULL (or near-NULL) dereferences: the running program's address space is still mapped when in kernel mode, so an attacker can map a page at 0, trigger a NULL dereference in the kernel and trick the kernel into doing something bad rather than oopsing.) Based on strace output, it seems that when the hint address to mmap is near mmap_min_addr and there is not enough room left nearby above mmap_min_addr, Linux might either return EPERM or give you a totally different memory block. So this is not exactly a simple case of running out of memory. It's likely that when we receive an EPERM from mmap with a hint address, then falling back to no hint address might give us another block. Then we could report an out-of-memory error if the mmap with no hint address also returned EPERM (though it might just return ENOMEM, instead). However, in my testing, the test program in the report was able to allocate 3068 MB of virtual address space when `mmap_min_addr` was not an issue (<= 1MB) and 2929 MB when it got EPERM due to `mmap_min_addr` (2MB), so there was only 139 MB of virtual address space left that it could have scrounged up with this strategy. I think that simply treating EPERM as an out-of-memory error would be an acceptable fix. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/7500#comment:5> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

Re: [GHC] #7980: runghc dies silently when given large numbers of arguments. Compiled code does not.
by GHC 25 Aug '13

25 Aug '13

#7980: runghc dies silently when given large numbers of arguments. Compiled code does not. ------------------------------------------------+-------------------------- Reporter: totherme | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.6.2 Resolution: | Keywords: Operating System: Linux | Architecture: x86_64 Type of failure: Incorrect result at runtime | (amd64) Test Case: | Difficulty: Blocking: | Unknown | Blocked By: | Related Tickets: ------------------------------------------------+-------------------------- Changes (by rwbarton): * difficulty: => Unknown Comment: In HEAD (thanks to commit df810a59d8 of process) your first command produces an error message: > `runghc: /home/rwbarton/bin/ghc: rawSystem: runInteractiveProcess: exec: resource exhausted (Argument list too long)` (What's going on here is that Linux has both a limit on the total size of the argument list, and the size of each individual argument; and `runghc` packs its entire argument list into a single argument to `ghc`. Your `$(seq 1 100000)` fits comfortably within the limit on the total argument list, but not within the limit on a single argument.) -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/7980#comment:2> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

Re: [GHC] #7788: Recursive type family causes <<loop>>
by GHC 25 Aug '13

25 Aug '13

#7788: Recursive type family causes <<loop>> ------------------------------------------------+-------------------------- Reporter: shachaf | Owner: Type: bug | simonpj Priority: normal | Status: new Component: Compiler (Type checker) | Milestone: 7.8.1 Resolution: | Version: 7.6.2 Operating System: Unknown/Multiple | Keywords: Type of failure: Incorrect result at runtime | Architecture: Test Case: | Unknown/Multiple Blocking: | Difficulty: | Unknown | Blocked By: | Related Tickets: ------------------------------------------------+-------------------------- Changes (by rwbarton): * cc: rwbarton@… (added) -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/7788#comment:2> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

Re: [GHC] #7056: GHCi loadArchive "libiconv.a":failed Unknown PEi386 section name `.drectve'
by GHC 25 Aug '13

25 Aug '13

#7056: GHCi loadArchive "libiconv.a":failed Unknown PEi386 section name `.drectve' ----------------------------+---------------------------------------------- Reporter: songpp | Owner: thoughtpolice Type: bug | Status: new Priority: high | Milestone: 7.8.1 Component: GHCi | Version: 7.4.1 Resolution: | Keywords: loadArchive Unknown PEi386 Operating System: Windows | Architecture: x86 Type of failure: GHCi | Difficulty: Unknown crash | Blocked By: 3658 Test Case: | Related Tickets: #2487, #7103 Blocking: | ----------------------------+---------------------------------------------- Comment (by simonmar): We should probably just ignore section names that we don't understand. I think the linker is just being extra paranoid in making sure it understands the whole contents of the object file, but this breaks with pretty much every new gcc/binutils. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/7056#comment:14> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

Re: [GHC] #7957: -ddump-minimal-imports should honour -outputdir
by GHC 25 Aug '13

25 Aug '13

#7957: -ddump-minimal-imports should honour -outputdir -------------------------------------+------------------------------------ Reporter: hvr | Owner: hvr Type: feature request | Status: patch Priority: normal | Milestone: Component: Compiler | Version: 7.0.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 hvr): * status: new => patch -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/7957#comment:4> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

Re: [GHC] #7957: -ddump-minimal-imports should honour -outputdir
by GHC 25 Aug '13

25 Aug '13

#7957: -ddump-minimal-imports should honour -outputdir -------------------------------------+------------------------------------ Reporter: hvr | Owner: hvr Type: feature request | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.0.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 hvr): * owner: => hvr Comment: The attached patch is an attempt at addressing this ticket in simple and pragmatic way by using the `-dumpdir` flag (if set) as base folder for the generated `.imports` files. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/7957#comment:3> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

Re: [GHC] #8113: Cannot override ghci builtin commands with :def[!]
by GHC 25 Aug '13

25 Aug '13

#8113: Cannot override ghci builtin commands with :def[!] -------------------------------------+------------------------------------- Reporter: duncan | Owner: Type: bug | Status: closed Priority: normal | Milestone: 7.8.1 Component: GHCi | Version: 7.6.3 Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: Other | Difficulty: Easy (less than 1 Test Case: | hour) ghci/scripts/T8113 | Blocked By: Blocking: | Related Tickets: -------------------------------------+------------------------------------- Changes (by hvr): * testcase: => ghci/scripts/T8113 -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/8113#comment:12> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0