GHC: Ticket Queryhttp://ghc.haskell.org/trac/ghc/query?component=Runtime+System&milestone=6.10+branch&group=status&order=id
The Glasgow Haskell Compileren-USGHChttp://ghc.haskell.org/trac/ghc/chrome/site/ghc_logo.pnghttp://ghc.haskell.org/trac/ghc/query?component=Runtime+System&milestone=6.10+branch&group=status&order=id
Trac 1.0.1http://ghc.haskell.org/trac/ghc/ticket/1589
http://ghc.haskell.org/trac/ghc/ticket/1589#1589: Process creation and communication doesn't scale linearlyMon, 06 Aug 2007 09:41:32 GMTguest<p>
Creating processes (with forkIO) and communicating between them (with putMVar and takeMVar) does not scale linearly. For 10000 processes creation takes 8us, but for 100000 it takes 60us. Even taking the increased GC into account it's highly non-linear.
</p>
Resultshttp://ghc.haskell.org/trac/ghc/ticket/1589#changeloghttp://ghc.haskell.org/trac/ghc/ticket/1619
http://ghc.haskell.org/trac/ghc/ticket/1619#1619: The RTS chokes on SIGPIPE (happens with runInteractiveCommand)Sat, 18 Aug 2007 23:35:23 GMTint-e<p>
Consider the following code.
</p>
<pre class="wiki">-- code based on example by steven_ashley on #haskell
import System.Process
import System.IO
import Control.Exception
main = do
data &lt;- readFile "core"
(inp,out,err,pid) &lt;- runInteractiveCommand "cat"
print "before"
finally (hPutStr inp data)
(print "after")
</pre><p>
This program, when run with a large enough <tt>core</tt> file in the current directory, will print <tt>"before"</tt> and then exit.
</p>
<p>
What happens (according to <tt>strace</tt>) is that the RTS closes the input end of the output pipe of the <tt>cat</tt> process (the one associated with the <tt>out</tt> variable). Then, <tt>cat</tt> tries to write some of its output and gets killed by <tt>SIGPIPE</tt>. This in turn closes the input end of its input pipe. When the Haskell program writes its next chunk of data, it is killed by <tt>SIGPIPE</tt> itself.
</p>
<p>
I believe the right fix for this is for the RTS to ignore <tt>SIGPIPE</tt>. The write syscall would then return <tt>EPIPE</tt> in the above scenario, which can be handled by the normal exception mechanism.
</p>
Resultshttp://ghc.haskell.org/trac/ghc/ticket/1619#changeloghttp://ghc.haskell.org/trac/ghc/ticket/1887
http://ghc.haskell.org/trac/ghc/ticket/1887#1887: internal error while running parallel programTue, 13 Nov 2007 19:02:11 GMTmrd<p>
Problems occur when I use parFlatMap instead of concatMap.
</p>
<p>
Appears to be non-deterministic, some kind of subtle threading-related
heap corruption.
</p>
<pre class="wiki">$ ghc --make -debug -threaded mat_mult_ndp
$ gdb ./mat_mult_ndp
(gdb) run -p 4 test5.mat out.mat +RTS -N4 -DS
mat_mult_ndp: internal error: ASSERTION FAILED: file Sanity.c, line 86
(GHC version 6.9.20071105 for x86_64_unknown_linux)
Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug
[New Thread 1124096336 (LWP 933)]
Program received signal SIGABRT, Aborted.
[Switching to Thread 1107310928 (LWP 931)]
0x0000003e076305b5 in raise () from /lib64/libc.so.6
(gdb) bt
#0 0x0000003e076305b5 in raise () from /lib64/libc.so.6
#1 0x0000003e07632060 in abort () from /lib64/libc.so.6
#2 0x000000000047f888 in rtsFatalInternalErrorFn (s=0x529948 "ASSERTION FAILED: file %s, line %u\n",
ap=0x42002d80) at RtsMessages.c:164
#3 0x000000000047f44c in barf (s=0x529948 "ASSERTION FAILED: file %s, line %u\n") at RtsMessages.c:40
#4 0x000000000047f4a6 in _assertFail (filename=0x5390b8 "Sanity.c", linenum=86) at RtsMessages.c:55
#5 0x00000000004b301e in checkClosureShallow (p=0x2aaaaafb0050) at Sanity.c:86
#6 0x00000000004b2efe in checkSmallBitmap (payload=0x2aaaaafb1378, bitmap=2, size=4) at Sanity.c:51
#7 0x00000000004b324c in checkStackFrame (c=0x2aaaaafb1370) at Sanity.c:144
#8 0x00000000004b3418 in checkStackChunk (sp=0x2aaaaafb1360, stack_end=0x2aaaaafb1400)
at Sanity.c:201
#9 0x00000000004b4a02 in checkTSO (tso=0x2aaaaafb1000) at Sanity.c:715
#10 0x00000000004833fb in threadStackOverflow (cap=0x7872b0, tso=0x2aaaaafb1000) at Schedule.c:2799
#11 0x0000000000481d90 in scheduleHandleStackOverflow (cap=0x7872b0, task=0x7b2bc0, t=0x2aaaaafb1000)
at Schedule.c:1658
#12 0x00000000004810e2 in schedule (initialCapability=0x7872b0, task=0x7b2bc0) at Schedule.c:694
#13 0x0000000000482f3b in workerStart (task=0x7b2bc0) at Schedule.c:2528
#14 0x0000003e096061c5 in start_thread () from /lib64/libpthread.so.0
#15 0x0000003e076d062d in clone () from /lib64/libc.so.6
</pre><p>
I tested it on an older install of GHC 6.7.20070831 and it had the same problem.
test5.mat is attached sample input describing two matrices of size nxn (=64 in this case). Smaller inputs didn't seem to tickle the bug, or at least, not often enough to be noticed.
</p>
Resultshttp://ghc.haskell.org/trac/ghc/ticket/1887#changeloghttp://ghc.haskell.org/trac/ghc/ticket/1891
http://ghc.haskell.org/trac/ghc/ticket/1891#1891: New RTS "--info" option not in help messageWed, 14 Nov 2007 11:53:48 GMTOrphi<p>
The release notes mention a new RTS option <tt>--info</tt>, which prints out various information about any GHC-compiled program. (I don't actually see anywhere that explains what this data is ment to mean, although much of it is self-explanatory.)
</p>
<p>
When a program is invoked with the RTS option <tt>-?</tt>, it prints a list of all accepted RTS options. However, <tt>--info</tt> is not listed. Presumably this is just an oversight?
</p>
Resultshttp://ghc.haskell.org/trac/ghc/ticket/1891#changeloghttp://ghc.haskell.org/trac/ghc/ticket/2131
http://ghc.haskell.org/trac/ghc/ticket/2131#2131: concprog001(threaded2) occasional failures.Thu, 28 Feb 2008 10:10:57 GMTsimonmar<p>
This one has so far resisted my attempts to debug it. The most common error is "thread blocked indefinitely": I don't know whether it's a bug in the RTS or allowed behaviour for this program, but it only seems to occur on a multiprocessor with <tt>+RTS -N2</tt>, and only in one out of 10 runs or so.
</p>
<p>
Also I've seen
</p>
<ul><li>hanging using 100% CPU without apparently making any progress
</li><li>another type of crash I didn't make a note of at the time.
</li></ul>Resultshttp://ghc.haskell.org/trac/ghc/ticket/2131#changeloghttp://ghc.haskell.org/trac/ghc/ticket/2272
http://ghc.haskell.org/trac/ghc/ticket/2272#2272: internal error: getMBlock: mmap: Bad file numberThu, 08 May 2008 14:04:50 GMThpwei<p>
I cut and paste the code from
<a class="ext-link" href="http://blog.moertel.com/articles/2004/03/13/concurrent-port-scanner-in-haskell"><span class="icon">​</span>http://blog.moertel.com/articles/2004/03/13/concurrent-port-scanner-in-haskell</a>
</p>
<p>
And compiled the resulting portscan.hs
with both ghc-6.8.2 and ghc-6.6.1
on a host with Sun-Sparc [SunOS 5.10].
</p>
<p>
The following error occurred when the code was invoked.
</p>
<pre class="wiki">portscan a_remote_sun_sparc_machine 1 1000
portscan: internal error: getMBlock: mmap: Bad file number
(GHC version 6.6.1 for sparc_sun_solaris2)
Please report this as a GHC bug:
http://www.haskell.org/ghc/reportabug
Abort
</pre><p>
[ note: same result for 6.8.2 ]
</p>
<p>
[ note: if the remote machine is a linux machine, then the code works. ]
</p>
<p>
--HP
</p>
Resultshttp://ghc.haskell.org/trac/ghc/ticket/2272#changeloghttp://ghc.haskell.org/trac/ghc/ticket/2651
http://ghc.haskell.org/trac/ghc/ticket/2651#2651: BlockedIndefinitely not thrown when it should beFri, 03 Oct 2008 20:39:13 GMTgovereau<p>
The following program demonstrates the bug.
When run with no arguments, the "die" thread gets a BlockedIndefinitely exception, when run with command line arguments it does not.
</p>
<pre class="wiki">module Main where
import Control.Monad
import Control.Concurrent
import Control.Concurrent.STM
import System.Environment
main :: IO ()
main = do { flags &lt;- getArgs
; if (length flags &gt; 0)
then forkIO die &gt;&gt; -- die does not die
threadDelay 10000000
else die -- die dies
}
-- expect BlockedIndefinitely exception to be thrown
die :: IO ()
die = newTVarIO "die" &gt;&gt;= f &gt;&gt;= print
where f tv = atomically $ do { x &lt;- readTVar tv
; if x == "die" then retry else return x
}
</pre>Resultshttp://ghc.haskell.org/trac/ghc/ticket/2651#changeloghttp://ghc.haskell.org/trac/ghc/ticket/3171
http://ghc.haskell.org/trac/ghc/ticket/3171#3171: threadDelay causes Ctrl-C to be ignored when running interpreted codeWed, 15 Apr 2009 21:53:38 GMTchowells<p>
the following program:
</p>
<pre class="wiki">import Control.Concurrent
import Control.Concurrent.MVar
main = threadDelay 0 &gt;&gt; newEmptyMVar &gt;&gt;= takeMVar
</pre><p>
will not respond to Ctrl-C when run via runghc, but does respond to Ctrl-C when compiled and executed.
</p>
<p>
If the threadDelay is removed, it does respond to Ctrl-C both compiled and interpreted.
</p>
<p>
In 6.10.1, Ctrl-C has the normal effect whether the program is run compiled or interpreted.
</p>
<p>
The editline segmentation fault bug prevented us from testing the behavior in ghci.
</p>
Resultshttp://ghc.haskell.org/trac/ghc/ticket/3171#changelog