GHC: Ticket Query
http://ghc.haskell.org/trac/ghc/query?component=Runtime+System&milestone=6.6&group=status&order=priority
The Glasgow Haskell Compileren-USGHChttp://ghc.haskell.org/trac/ghc/chrome/site/ghc_logo.png
http://ghc.haskell.org/trac/ghc/query?component=Runtime+System&milestone=6.6&group=status&order=priority
Trac 1.0.1
http://ghc.haskell.org/trac/ghc/ticket/652
http://ghc.haskell.org/trac/ghc/ticket/652#652: Have a single Data.Typeable hash table in GHCiFri, 13 Jan 2006 12:38:54 GMTsimonmar<p>
The hash table used by <tt>Data.Typeable</tt> is declared as a top-level IORef. This means in GHCi, there will be two <tt>Data.Typeable</tt> hash tables: one in the dynamically-loaded base package, and one in the statically-linked GHCi binary. Therefore Dyanmics created in one world are incompatible with the other world.
</p>
<p>
We have a hack to make sure the two hash tables don't use the same uniques, so at least a <tt>TypeRep</tt> created in one world will <em>never</em> compare equal to a <tt>TypeRep</tt> from the other world (before this hack we could different <tt>TypeRep</tt>s bogusly claiming to be equal). However, we would like them to compare equal when they are equal.
</p>
<p>
This implies that the packages in use in both world must be compatible (preferably identical). This is because when a <tt>TypeRep</tt> compares equal, we must be sure that the value has the representation we expect. Fortunately this is the case in a stage2 GHC.
</p>
<p>
We should store a ptr (<tt>StablePtr</tt>?) to the hash table in an RTS global, so that there is only one per runtime instance.
</p>
Resultshttp://ghc.haskell.org/trac/ghc/ticket/652#changelog
http://ghc.haskell.org/trac/ghc/ticket/713
http://ghc.haskell.org/trac/ghc/ticket/713#713: SMP + FFI = crash...Fri, 03 Mar 2006 23:18:10 GMTlipeng@…<p>
Source code will be attached. This is a modified version of bug <a class="closed ticket" href="http://ghc.haskell.org/trac/ghc/ticket/705" title="bug: crash on readChan/writeChan (closed: fixed)">#705</a>: each thread calls a safe C function via FFI. The normal behavior of the program is to loop forever. The program works fine using +RTS -N1, but when using +RTS -N2 or more threads on a SMP machine, it crashes nondeterministically with all kinds of funny error messages. I can reproduce it on difference linux SMP machines.
</p>
Resultshttp://ghc.haskell.org/trac/ghc/ticket/713#changelog
http://ghc.haskell.org/trac/ghc/ticket/756
http://ghc.haskell.org/trac/ghc/ticket/756#756: Threaded RTS deadlock when used with Visual HaskellWed, 26 Apr 2006 08:03:23 GMTsimonmar<p>
It has been reported that the threaded RTS on the HEAD doesn't work with Visual Haskell, apparently it hangs.
</p>
<p>
Reported by Krasimir Angelov, here:
</p>
<p>
<a class="ext-link" href="http://www.haskell.org//pipermail/cvs-ghc/2006-February/028529.html"><span class="icon"></span>http://www.haskell.org//pipermail/cvs-ghc/2006-February/028529.html</a>
</p>
Resultshttp://ghc.haskell.org/trac/ghc/ticket/756#changelog
http://ghc.haskell.org/trac/ghc/ticket/805
http://ghc.haskell.org/trac/ghc/ticket/805#805: Too many workers; runaway worker creation?Mon, 26 Jun 2006 23:43:45 GMTlipeng@…<p>
See the attached code. Use "make" to compile and you should get an executable file called "Bug.bin", then you can run it by typing the command "./Bug.bin N" where N is the number of concurrent threads.
</p>
<p>
For N<=32. The program works fine. It will simply loop and you need another terminal to kill it.
</p>
<p>
For N>32, it always crashes immediately:
</p>
<pre class="wiki">$ ./Bug.bin 33
Bug.bin: internal error: too many workers; runaway worker creation?
(GHC version 6.5.20060620 for i386_unknown_linux)
Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug
Aborted
</pre>Resultshttp://ghc.haskell.org/trac/ghc/ticket/805#changelog
http://ghc.haskell.org/trac/ghc/ticket/645
http://ghc.haskell.org/trac/ghc/ticket/645#645: Make tick interval configurableWed, 04 Jan 2006 10:46:00 GMTsimonmar<p>
The hardwired tick interval of 0.02 seconds is too long. We should make this shorter, and preferably configurable at runtime by an RTS option.
</p>
Resultshttp://ghc.haskell.org/trac/ghc/ticket/645#changelog
http://ghc.haskell.org/trac/ghc/ticket/688
http://ghc.haskell.org/trac/ghc/ticket/688#688: killThread and SMPThu, 09 Feb 2006 11:21:56 GMTsimonmar<p>
killThread currently doesn't work with SMP, unless you only use one CPU. This should either work (preferably), or give a reasonable error message.
</p>
Resultshttp://ghc.haskell.org/trac/ghc/ticket/688#changelog
http://ghc.haskell.org/trac/ghc/ticket/747
http://ghc.haskell.org/trac/ghc/ticket/747#747: Unloading a dll does not clean up properlyMon, 17 Apr 2006 16:21:39 GMTguest<p>
When a DLL is loaded it calls initUserSignals() and initDefaultHandlers().
This sets up some signal (event) handlers.
When the DLL is unloaded it does not remove those handlers.
This means that if the events happen after the DLL has been unloaded
it will dispatch into non-loaded code. This is, obviously, bad.
</p>
<p>
It's very dubious if a DLL should install these handlers at all.
At least there should be a flag if they should be installed or not.
And if installed they should be removed on exit.
</p>
Resultshttp://ghc.haskell.org/trac/ghc/ticket/747#changelog
http://ghc.haskell.org/trac/ghc/ticket/814
http://ghc.haskell.org/trac/ghc/ticket/814#814: RTS always grabs 256Mb on startupWed, 05 Jul 2006 14:34:03 GMTsimonmar<p>
Two bugs really:
</p>
<ul><li>on Windows, the RTS always reserves 256Mb of memory on startup.
</li><li>to use more than 256Mb, you have to use +RTS -M
</li></ul><p>
I think this is a hangover from the days before HEAP_ALLOCED was implemented with an array lookup; I believe we could now implement MBlock on Windows without these drawbacks.
</p>
Resultshttp://ghc.haskell.org/trac/ghc/ticket/814#changelog