GHC: Ticket Queryhttp://ghc.haskell.org/trac/ghc/query?status=closed&component=Runtime+System&milestone=6.12.3&group=resolution&order=priority
The Glasgow Haskell Compileren-USGHChttp://ghc.haskell.org/trac/ghc/chrome/site/ghc_logo.pnghttp://ghc.haskell.org/trac/ghc/query?status=closed&component=Runtime+System&milestone=6.12.3&group=resolution&order=priority
Trac 1.0.1http://ghc.haskell.org/trac/ghc/ticket/4038
http://ghc.haskell.org/trac/ghc/ticket/4038#4038: segmentation fault between GHC-6.12.2 and gtk2hsMon, 03 May 2010 05:45:29 GMTguest<p>
I have test gtk2hs code with GHC-6.12.2, always got "segmentation fault", and same code works fine with GHC-6.12.1
</p>
<p>
I can't give a minimum program to recur this.
</p>
<p>
But i think GHC-6.12.2 break many gtk2hs binding that make gtk2hs code access null pointer to got "segmentation fault", and it's not fault of gtk2hs, because same version gtk2hs works fine with 6.10 and 6.12.1.
</p>
<p>
For test, you can install leksah with 6.12.2, i think Leksah will got "segmentation fault" error.
</p>
<p>
Can any GHC developer start a investigation?
</p>
<p>
Thanks,
</p>
<blockquote>
<p>
-- Andy
</p>
</blockquote>
Resultshttp://ghc.haskell.org/trac/ghc/ticket/4038#changeloghttp://ghc.haskell.org/trac/ghc/ticket/3890
http://ghc.haskell.org/trac/ghc/ticket/3890#3890: runghc sometimes won't allow redirecting of stdout/stderrSat, 20 Feb 2010 01:48:16 GMTsimonmic<p>
See attached test.hs. Here's stdout working normally:
</p>
<pre class="wiki">$ runhaskell test.hs | cat
output
$
</pre><p>
But after uncommenting either the cmdArgs line or the defaultMainWithArgs line, stdout can't be captured:
</p>
<pre class="wiki">$ runhaskell test.hs | cat
$
</pre><p>
It does appear on the console if you don't redirect though. The same goes for stderr. This prevents me testing uncompiled scripts with shelltestrunner. I'm on mac os 10.5.
</p>
Resultshttp://ghc.haskell.org/trac/ghc/ticket/3890#changeloghttp://ghc.haskell.org/trac/ghc/ticket/4010
http://ghc.haskell.org/trac/ghc/ticket/4010#4010: Confusing help for +RTS -eSat, 24 Apr 2010 07:29:27 GMTrl<p>
This is an excerpt from +RTS --help:
</p>
<pre class="wiki"> -e&lt;size&gt; Size of spark pools (default 100)
-e&lt;n&gt; Maximum number of outstanding local sparks (default: 4096)
</pre><p>
This happens with 6.10, 6.12 and the HEAD.
</p>
Resultshttp://ghc.haskell.org/trac/ghc/ticket/4010#changeloghttp://ghc.haskell.org/trac/ghc/ticket/4074
http://ghc.haskell.org/trac/ghc/ticket/4074#4074: Forking not possible with large processesSat, 15 May 2010 20:28:43 GMTnomeata<p>
If a haskell program requires a lot of memory, trying to fork() fails because, due to the program size, the clone() syscall takes long and will interrupted by the ghc runtime timer, restarting the syscall, just to be interrupted again.
</p>
<p>
This happens repeatedly with ghc 6.12, which seems to require noticeable more memory than 6.10, when building large Haskell programs on slower arches, and causes some problems with Haskell in Debian.
</p>
<p>
The problem can also be observed by running a simple C program that malloc’s a lot of memory (in the range of 1G) and then tries to fork with profiling enabled.
</p>
<p>
In the corresponding Debian bug report against libc (<a class="ext-link" href="http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=575534"><span class="icon">​</span>http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=575534</a>), which also has the demo C code, it was suggested that it might be the program’s responsibility to disable such timers while clone() runs.
</p>
<p>
Do you agree with that? Is it something you can do? Might this be related to <a class="closed ticket" href="http://ghc.haskell.org/trac/ghc/ticket/1882" title="bug: GHC's vfork() silently dies, which renders compiling impossible (cyclic ... (closed: duplicate)">#1882</a> (which mentions timers and fork)?
</p>
Resultshttp://ghc.haskell.org/trac/ghc/ticket/4074#changeloghttp://ghc.haskell.org/trac/ghc/ticket/3918
http://ghc.haskell.org/trac/ghc/ticket/3918#3918: Got internal error: stg_ap_v_ret when call forkProcessFri, 12 Mar 2010 15:27:45 GMTguest<p>
For recur this bug, you need install gtk2hs, dbus-core, dbus-client first.
</p>
<p>
Then use below command to compile:
</p>
<pre class="wiki">ghc --make -threaded Main.hs
</pre><p>
Then run <tt>./Main</tt> in terminal, and press key "c" in program, then it will create new tab in program.
</p>
<p>
For recur this bug, you need press "c" sometimes (4 or 5 at least), then you will got below error:
</p>
<pre class="wiki">***************
Debug-&gt; in socket process (before `forkProcess`):
Main: internal error: stg_ap_v_ret
(GHC version 6.12.1 for x86_64_unknown_linux)
Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug
</pre><p>
I have test, this bug just happen when i call function <tt>forkProcess</tt>.
</p>
<p>
You can get source code from attach.
</p>
<blockquote>
<p>
-- Andy
</p>
</blockquote>
Resultshttp://ghc.haskell.org/trac/ghc/ticket/3918#changeloghttp://ghc.haskell.org/trac/ghc/ticket/3923
http://ghc.haskell.org/trac/ghc/ticket/3923#3923: internal error: throwTo: unrecognised why_blocked value (6.12.1)Tue, 16 Mar 2010 21:40:42 GMTjlouis<p>
Basically just a heads up that I saw ticket <a class="closed ticket" href="http://ghc.haskell.org/trac/ghc/ticket/2833" title="bug: internal error: throwTo: unrecognised why_blocked value (closed: fixed)">#2833</a> again:
</p>
<pre class="wiki">HaskellTorrent: internal error: throwTo: unrecognised why_blocked value
(GHC version 6.12.1 for x86_64_unknown_linux)
Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug
Aborted
</pre><p>
This is the first time it happens to me, and I make a *lot* of runs. When it happened I had lost all of the context of the running program, sadly, so I have no idea at where to dig. Is there any way I can help you with this? For my own reference, it is this commit from HaskellTorrent that produced the internal RTS error:
</p>
<pre class="wiki">commit e7d2fcf771faca6bdd69112825a1281f8b993dfe
</pre><p>
I have no reproducible test case for the bug at all either. But I am reporting the problem anyway. Output from the RTS:
</p>
<pre class="wiki">jlouis@illithid:~/torrenttest$ ./HaskellTorrent +RTS --info
[("GHC RTS", "YES")
,("GHC version", "6.12.1")
,("RTS way", "rts_p")
,("Host platform", "x86_64-unknown-linux")
,("Host architecture", "x86_64")
,("Host OS", "linux")
,("Host vendor", "unknown")
,("Build platform", "x86_64-unknown-linux")
,("Build architecture", "x86_64")
,("Build OS", "linux")
,("Build vendor", "unknown")
,("Target platform", "x86_64-unknown-linux")
,("Target architecture", "x86_64")
,("Target OS", "linux")
,("Target vendor", "unknown")
,("Word size", "64")
,("Compiler unregisterised", "NO")
,("Tables next to code", "YES")
]
</pre>Resultshttp://ghc.haskell.org/trac/ghc/ticket/3923#changelog