#4210: LLVM: Dynamic Library Support
---------------------------------+------------------------------------------
Reporter: dterei | Owner: dterei
Type: feature request | Status: new
Priority: low | Milestone: 7.6.2
Component: Compiler (LLVM) | Version: 6.13
Keywords: | Os: Unknown/Multiple
Architecture: Unknown/Multiple | Failure: Runtime crash
Difficulty: | Testcase:
Blockedby: | Blocking:
Related: |
---------------------------------+------------------------------------------
Comment(by dterei):
No more progress. If anything, perhaps things have regressed as I haven't
looked at dynlib support in LLVM for a fair while. If status is the same
though I don't know how much it is worth worrying about supporting 32bit.
--
Ticket URL: <http://hackage.haskell.org/trac/ghc/ticket/4210#comment:23>
GHC <http://www.haskell.org/ghc/>
The Glasgow Haskell Compiler
#7908: InstanceSigs suggestion not accepted
-----------------------------+----------------------------------------------
Reporter: heisenbug | Owner:
Type: bug | Status: new
Priority: normal | Component: Compiler
Version: 7.7 | Keywords:
Os: Unknown/Multiple | Architecture: Unknown/Multiple
Failure: None/Unknown | Blockedby:
Blocking: | Related:
-----------------------------+----------------------------------------------
Attached testcase compiles, but when
uncommenting either of the lines 19, 21 or 23,
I get an error:
{{{
pr7908.hs:23:12:
Method signature does not match class; it should be
(>>-) :: forall (c :: k -> *) d.
Hidden k c -> (forall (a :: k). c a -> d) -> d
In the instance declaration for `Monad' k (Hidden k)'
Failed, modules loaded: none.
}}}
But in fact I basically copied the suggestion into my file! (with slight
modification "Hidden k c" --> "Hidden c")
This may be because of the rank2 type or because of the polykinds
appearing.
--
Ticket URL: <http://hackage.haskell.org/trac/ghc/ticket/7908>
GHC <http://www.haskell.org/ghc/>
The Glasgow Haskell Compiler
#7831: Bad fragmentation when allocating many large objects
-----------------------------+----------------------------------------------
Reporter: ezyang | Owner: ezyang
Type: bug | Status: new
Priority: normal | Component: Runtime System
Version: 7.7 | Keywords:
Os: Unknown/Multiple | Architecture: Unknown/Multiple
Failure: None/Unknown | Blockedby:
Blocking: | Related:
-----------------------------+----------------------------------------------
Consider our good old friend, the space-leaky list program:
{{{
import Control.Exception
import System.Environment
f n = let xs = [1..n] in sum xs * product xs
main = do
[n] <- getArgs
evaluate (f (read n :: Integer))
}}}
It is not surprising that this program is quite the memory guzzler; what
is surprising is how much GHC *wastes* when evaluating this program:
{{{
Fragmentation, wanted 95 blocks, 105 MB free
}}}
(For reference, a block is 4k, so 95 blocks is a measly 380k!) The
magnitude of the problem can be seen in this graphic:
[[Image(http://web.mit.edu/~ezyang/Public/fragmentation-ghc.png)]]
(The x-axis takes advantage of the fact that the number of requested
blocks increases ~linearly over time, since we keep multiplying the
integer which adds a constant number of extra bytes to the representation;
unused free memory corresponds to blocks of free memory in GHC's free
list, which it is holding onto from the OS but not using to store user
data.)
When the requested allocations are *just* large enough (just slightly over
half a megablock, or 128 blocks), we start allocating a megablock per
allocation and waste half of the megablock, since none of the leftovers
are ever large enough to store any of the later allocations.
Can we do anything about this? One possibility is to occasionally check
how much space we're losing to fragmentation, and everyone once in a while
pay the cost of copying tenured large objects and pack them together in a
megablock group (obviously one wants to avoid doing this too often, since
copying large objects is expensive!) I'm open to better suggestions
though! (Apologies if this is a duplicate; I didn't see any open tickets
with the word "fragmentation" in them).
--
Ticket URL: <http://hackage.haskell.org/trac/ghc/ticket/7831>
GHC <http://www.haskell.org/ghc/>
The Glasgow Haskell Compiler
#7841: Stage1Only conditional program/package building
-----------------------------+----------------------------------------------
Reporter: elliottt | Owner:
Type: feature request | Status: new
Priority: normal | Component: Build System
Version: 7.7 | Keywords: Stage1Only
Os: Unknown/Multiple | Architecture: Unknown/Multiple
Failure: None/Unknown | Blockedby:
Blocking: | Related:
-----------------------------+----------------------------------------------
This patch includes changes to allow programs and packages to be disabled
by stage when building GHC.
== rule/build-package.mk ==
* Add guards for "disable-$(dir)-$(stage)" around the rule body
== rule/build-prog.mk ==
* Add guards for "disabled-$(dir)-$(stage)" around the rule body
== mk/build.mk.default ==
* Add a set of package disabling definitions when $(Stage1Only) is set
to "YES"
== rts/ghc.mk ==
* Add the all_rts target as a dependency for all, causing the rts to
build when packages that depend on it are disabled
--
Ticket URL: <http://hackage.haskell.org/trac/ghc/ticket/7841>
GHC <http://www.haskell.org/ghc/>
The Glasgow Haskell Compiler
#7905: Type checker barfs on nonsensical expression
-------------------------------+--------------------------------------------
Reporter: jpaugh | Owner:
Type: bug | Status: new
Priority: normal | Component: Compiler
Version: 7.6.2 | Keywords:
Os: Linux | Architecture: x86
Failure: Compile-time crash | Blockedby:
Blocking: | Related:
-------------------------------+--------------------------------------------
I got the infamous "impossible bug" by trying something nonsensical in my
program. I reproduced the bug in the attached minimal program (18 lines).
The precise error message is:
{{{
Impossible.hs:18:5:
Couldn't match kind `* -> *' with `*'
Expected type: [Char] -> ZT IO ()
Actual type: [Char] -> ZT IO ()
Kind incompatibility when matching types:
[Char] :: * -> *
[Char] :: *
The function `lift'ghc: panic! (the 'impossible' happened)
(GHC version 7.6.2 for i386-unknown-linux):
kindFunResult ghc-prim:GHC.Prim.*{(w) tc 34d}
}}}
Note that this error occurs whether on not the ''MonadTrans'' instance is
there.
--
Ticket URL: <http://hackage.haskell.org/trac/ghc/ticket/7905>
GHC <http://www.haskell.org/ghc/>
The Glasgow Haskell Compiler
#7726: unexpected out of memory error on FreeBSD
-------------------------------+--------------------------------------------
Reporter: nejstastnejsistene | Owner:
Type: bug | Status: new
Priority: normal | Component: Runtime System
Version: 7.4.2 | Keywords:
Os: FreeBSD | Architecture: x86
Failure: Runtime crash | Blockedby:
Blocking: | Related:
-------------------------------+--------------------------------------------
I wrote a daemon that periodically scrapes information from a webpage that
crashes after about 20 hours with the error: "out of memory (requested
1048576 bytes)". The program runs fine on my Ubuntu machine, but always
crashes on FreeBSD even though there is plenty of memory to spare/memory
stays constant/etc.
I boiled it down to the following code, which consistently crashes after
about 4000-6000 iterations when compiled with -O2, and about 35000
without.
{{{
import Data.Conduit
import Data.Conduit.List
import qualified Data.ByteString as B
import Network.HTTP.Conduit
main :: IO ()
main = do
manager <- newManager def
loop manager 1
loop :: Manager -> Int -> IO ()
loop manager i = do
putStrLn $ show i
request <- parseUrl "http://localhost:8000/courselist.html"
html <- runResourceT $ do
response <- http request manager
fmap B.concat $ responseBody response $$+- consume
loop manager $ i + 1
}}}
For debugging, I served a copy of of a typical html sample from localhost
using "python -m SimpleHTTPServer". The html file is attached.
Sample Output:[[BR]]
{{{
...
35361
35362
35363
35364
35365
main: out of memory (requested 1048576 bytes)
}}}
Other information:
{{{
$ uname -a
FreeBSD oriskova 9.1-RELEASE FreeBSD 9.1-RELEASE #0 r243826: Tue Dec 4
06:55:39 UTC 2012
root@obrian.cse.buffalo.edu:/usr/obj/usr/src/sys/GENERIC i386
}}}
{{{
$ gcc -v
Using built-in specs.
Target: i386-undermydesk-freebsd
Configured with: FreeBSD/i386 system compiler
Thread model: posix[[BR]]
gcc version 4.2.1 20070831 patched [FreeBSD]
}}}
I wasn't sure if I should submit this or not since it seemed fairly
specific to http-conduit, but the wiki said to go ahead and submit runtime
errors, so that's what I did. This is my first time ever submitting a bug
report and I tried my best to follow all the instructions at
[http://hackage.haskell.org/trac/ghc/wiki/ReportABug] but please tell me
if there is something I'm doing wrong.
--
Ticket URL: <http://hackage.haskell.org/trac/ghc/ticket/7726>
GHC <http://www.haskell.org/ghc/>
The Glasgow Haskell Compiler
){kind=link}