GHC: Ticket Queryhttp://ghc.haskell.org/trac/ghc/query?milestone=6.12.2&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?milestone=6.12.2&group=status&order=id
Trac 1.0.1http://ghc.haskell.org/trac/ghc/ticket/414
http://ghc.haskell.org/trac/ghc/ticket/414#414: GHC does not eforce that Main exports mainWed, 06 Jul 2005 09:19:26 GMTsimonpj<pre class="wiki">The Haskell 98 report says "A Haskell program is a
collection of
modules, one of which, by convention, must be called
Main and must
export the value main." However, the program below
builds and executes
fine.
module Main() -- should be "module Main" or "module
Main(main)"
where
main = putStrLn "Hello, World"
$ runghc Main.hs
Hello, World
Originally reported by Brian Smith
[brianlsmith@gmail.com]
</pre>Resultshttp://ghc.haskell.org/trac/ghc/ticket/414#changeloghttp://ghc.haskell.org/trac/ghc/ticket/650
http://ghc.haskell.org/trac/ghc/ticket/650#650: Improve interaction between mutable arrays and GCWed, 11 Jan 2006 11:21:00 GMTsimonmar<p>
This is the result of a discussion between myself and Simon PJ a few weeks ago, inspired by recent discoveries of poor performance with mutable arrays (eg. see Data.Hash discussion on glasgow-haskell-users around October 2005).
</p>
<p>
Note that all this applies to mutable arrays of pointers, i.e. <tt>IOArray</tt> and <tt>STArray</tt>, <em>not</em> to unboxed arrays, i.e. <tt>IOUArray</tt> and <tt>STUArray</tt>.
</p>
<h3 id="Currentimplementation">Current implementation</h3>
<p>
There are two primitive types: <tt>MutArray#</tt> and <tt>Array#</tt>. We convert between them with:
</p>
<pre class="wiki"> unsafeFreezeArray# :: MutArr# s a -&gt; State# s -&gt; (# State# s, Array# a #)
unsafeThawArray# :: Array# a -&gt; State# s -&gt; (# State# s, MutArr# s a #)
</pre><p>
An Arr# is not normally on the old-gen mutable list, unless (a) it has pointers to young gen objects, or (b) it has been recently frozen. The implementation of <tt>unsafeFreezeArray#</tt> is a single write to the header word of the array. The implementation of <tt>unsafeThawArray#</tt> is slightly more complex: if the array was not already on the mutable list (indicated by the value of the header), then we add it. Also, we change the header word to indicate that the array is now mutable.
</p>
<p>
A <tt>MutArr#</tt> is <em>always</em> on the mutable list.
</p>
<p>
Objects pointed to by Array# are <em>eagerly promoted</em> to the generation in which the Array# resides, with the aim that the Array# can then be removed from the mutable list.
</p>
<p>
It is only safe to write to a <tt>MutArr#</tt>, so if multiple threads are accessing an array, they should <em>not</em> be doing thaw/freeze tricks without extra locking around the array (such behaviour can cause the GC to crash).
</p>
<h3 id="TheProblem">The Problem</h3>
<p>
The problem is that mutable arrays are always completely traversed on every GC. To get around this, we can keep an array in a frozen state and thaw it just before writing, then freeze it again afterward. This is a bit inconvenient, not to mention unsafe with multiple threads unless extra locking is used.
</p>
<p>
Furthermore, a modified array is <em>completely</em> scanned, whereas for larger arrays it would be much better to just scan the part of the array that had been modified (known in the GC literature as "card-marking").
</p>
<p>
The benefit of the current approach is that writing to a mutable array is a single write instruction, whereas to do card-marking or something else requires a write-barrier. The unsafeThaw/write/unsafeFreeze sequence amounts to a write barrier, so if this is a common technique we should provide an easy way to do it, possibly making it the default.
</p>
<h3 id="Solutions">Solutions</h3>
<p>
Leaving aside card-marking for now, let's think about incorporating the write barrier in the write operation.
</p>
<p>
Suppose that mutable arrays are <em>always</em> kept on the mutable list, but the header word indicates whether the array needs to be scanned or not (eg. we have <tt>MUT_ARR_DIRTY</tt>, <tt>MUT_ARR_CLEAN</tt>). The array write op should (a) set the header to <tt>MUT_ARR_DIRTY</tt>, and (b) do the write. The GC turns <tt>MUT_ARR_DIRTY</tt> into <tt>MUT_ARR_CLEAN</tt> when everything the array points to is in the same generation (or older).
</p>
<p>
Downsides to this:
</p>
<ul><li>intitialising a mutable array, or doing block writes, will be
more painful, because each write will have the write barrier
(perhaps not too painful)
</li></ul><p>
How does freezing/thawing interact with this? We currently create immutable arrays by starting with a <tt>MutArr#</tt>, intitialising it, and then freezing it to make an <tt>Arr#</tt>. We can still do this, exactly as now (and with the same thread-unsafety), but initialization will be a bit slower due to the write barrier.
</p>
<h3 id="Blockwrites">Block writes</h3>
<p>
We could try to provide for "block writes", by allowing a thread to "open" the array for modification, and then "close" it again after it had finished writing, with all writes in between being done without a write barrier. This would replace unsafeThaw/unsafeFreeze.
</p>
<p>
To do this safely, we would have to use some kind of synchronisation on the open/close; techniques that we came up with were to increment (atomically) a counter in the array header, or to allocate a new heap object pointing to the array in the current thread's allocation area.
</p>
<h3 id="Cardmarking">Card marking</h3>
<p>
We could refine the write barrier so that it marks just part of the array as dirty, instead of the whole array. The natural choice is to put the mark bit in the block descriptor for the current block, giving us a granularity of 4/8k, which is possibly a bit large but other solutions are much more expensive. Even this would significantly increase the cost of the write barrier, so it may be that we want a different kind of array type for this (<tt>LargeMutArr#</tt>?). Furthermore, currently not all arrays have their own block descriptors ("large objects" in GHC's storage manager), the small ones are allocated in movable memory. To do this, we would have to ensure that every array had its own block (or check in the write barrier, which adds even more expense).
</p>
<h2 id="IORefs">IORefs</h2>
<p>
This also affects IORefs, which are essentially single-element IOArrays. I just noticed that GHC often has a large number of IORefs hanging around in the heap from the typechecker, and the cost of traversing the mutable list can dominate minor GCs.
</p>
Resultshttp://ghc.haskell.org/trac/ghc/ticket/650#changeloghttp://ghc.haskell.org/trac/ghc/ticket/2578
http://ghc.haskell.org/trac/ghc/ticket/2578#2578: "ld: atom sorting error for ..." on OS XSun, 07 Sep 2008 22:09:10 GMTigloo<p>
I'm seeing <tt>atom sorting error</tt>s while building GHC on OS X, e.g.:
</p>
<pre class="wiki">Configuring ghc-bin-6.9...
/Users/ian/ghc/darcs/val/libraries/cabal-bin /usr/bin/ghc /Users/ian/ghc/darcs/val/libraries/bootstrapping.conf build --distpref dist-stage2
Preprocessing executables for ghc-bin-6.9...
Building ghc-bin-6.9...
[1 of 1] Compiling Main ( Main.hs, dist-stage2/build/ghc/ghc-tmp/Main.o )
Linking dist-stage2/build/ghc/ghc ...
ld: atom sorting error for _ghczm6zi9_LibFFI_Czuffizutype_closure_tbl and _ghczm6zi9_LibFFI_Czuffizucif_closure_tbl in /Users/ian/ghc/darcs/val/compiler/dist-stage2/build/libHSghc-6.9.a(LibFFI.o)
ld: atom sorting error for _ghczm6zi9_LibFFI_Czuffizutype_closure_tbl and _ghczm6zi9_LibFFI_Czuffizucif_closure_tbl in /Users/ian/ghc/darcs/val/compiler/dist-stage2/build/libHSghc-6.9.a(LibFFI.o)
</pre><p>
It doesn't seem to cause any problems, but it's a little worrying.
</p>
Resultshttp://ghc.haskell.org/trac/ghc/ticket/2578#changeloghttp://ghc.haskell.org/trac/ghc/ticket/2797
http://ghc.haskell.org/trac/ghc/ticket/2797#2797: ghci stack overflows when ghc does notFri, 21 Nov 2008 16:21:44 GMTTristanAllwood<p>
Happens with today's HEAD and 6.10.1
</p>
<p>
I appreciate I am playing a little fast and loose by using unsafePerformIO.
</p>
<pre class="wiki">module Main where
import System.IO.Unsafe
main :: IO ()
main = do
bar [] 5000000 `seq` return ()
bar :: [()] -&gt; Int -&gt; Int
bar stk 0 = error $ show stk
bar stk n = stk `seq` bar (push stk) (n-1)
push :: [()] -&gt; [()]
push stk = unsafePerformIO . return $ take 2 (():stk)
</pre><pre class="wiki">$ ~/ghc/ghc/ghc/stage2-inplace/ghc -O0 --make -o GT2 ghciTest2.hs
[1 of 1] Compiling Main ( ghciTest2.hs, ghciTest2.o )
Linking GT2.exe ...
t-trallw@MSRC-1326435 ~/ghc/ghc-Stack-Tests
$ ./GT2.exe +RTS -k0.01k -K0.01k
GT2.exe: [(),()]
t-trallw@MSRC-1326435 ~/ghc/ghc-Stack-Tests
$ rm *.o *.exe *.hi ; ~/ghc/ghc/ghc/stage2-inplace/ghc -e 'main' ghciTest2.hs +RTS -K40M
Stack space overflow: current size 40000000 bytes.
Use `+RTS -Ksize' to increase it.
</pre><p>
Using <tt>-K400M</tt> ghci does get there.
</p>
Resultshttp://ghc.haskell.org/trac/ghc/ticket/2797#changeloghttp://ghc.haskell.org/trac/ghc/ticket/2929
http://ghc.haskell.org/trac/ghc/ticket/2929#2929: INFINITY used in .hc files without -std=c99Fri, 09 Jan 2009 13:15:55 GMTduncan<p>
The C macro <tt>INFINITY</tt> is apparently defined by the C99 standard. On Solaris they take a strict interpretation of this and only define it conditionally:
</p>
<pre class="wiki">#if defined(_STDC_C99) || _XOPEN_SOURCE - 0 &gt;= 600 || defined(__C99FEATURES__)
</pre><p>
ghc does not use <tt>gcc -std=c99</tt> but perhaps it should? This bug is triggered by test 1861 (See <a class="closed ticket" href="http://ghc.haskell.org/trac/ghc/ticket/1861" title="merge: Uncompilable code generated (closed: fixed)">#1861</a>).
</p>
Resultshttp://ghc.haskell.org/trac/ghc/ticket/2929#changeloghttp://ghc.haskell.org/trac/ghc/ticket/2966
http://ghc.haskell.org/trac/ghc/ticket/2966#2966: build system does not respect --with-gcc=Mon, 19 Jan 2009 17:29:10 GMTduncan<p>
The ./configure scripts for all the core libs do not respect the <tt>--with-gcc=</tt> flag. The current build system passes this flag but it gets ignored.
</p>
<p>
This means that overall the ghc build does not respect the <tt>--with-gcc=</tt> flag. This is kind of annoying for doing a build on Solaris, since we have to use a gcc other than the standard system one.
</p>
<p>
When using a 'fake' gcc on the <tt>$PATH</tt> (a shell script that always fails), we get:
</p>
<pre class="wiki">ghc/libraries/unix $ ./configure --with-gcc=/opt/gcc-vanilla/4.1.2/bin/gcc
configure: WARNING: unrecognized options: --with-gcc
checking for gcc... gcc
checking for C compiler default output file name...
configure: error: in `/home/duncan/prgs/ghc/libraries/unix':
configure: error: C compiler cannot create executables
See `config.log' for more details.
</pre><p>
The same problem occurs with: base, directory, process, old-time and editline. These are all of the core packages that use <tt>./configure</tt> scripts.
</p>
<p>
On the other hand they all seem to check the <tt>CC</tt> environment variable.
</p>
<p>
Perhaps the ghc build system should pass <tt>--with-gcc=</tt> to the Cabal Setup, and perhaps that should call configure with <tt>CC</tt> set.
</p>
<p>
The problem applies to ghc-6.8.3 and ghc-HEAD (so probably also 6.10.x).
</p>
Resultshttp://ghc.haskell.org/trac/ghc/ticket/2966#changeloghttp://ghc.haskell.org/trac/ghc/ticket/3130
http://ghc.haskell.org/trac/ghc/ticket/3130#3130: copyFile and findExecutable don't work correctly if filename has national symbolsSun, 29 Mar 2009 09:10:48 GMTshelarcy<p>
copyFile works doesn't work if first argument's filename has national symbols.
</p>
<pre class="wiki">import System.Directory
main = do
copyFile "test.txt" "テスト.txt" -- works
print "copyFile works if second argument has national path."
copyFile "テスト.txt" "test2.txt" -- doesn't work
print "copyFile doesn't work if second argument has national path."
copyFile "テスト.txt" "テスト2.txt" -- doesn't work
print "copyFile doesn't work if first argument has national path."
</pre><pre class="wiki">C:\home&gt;runghc.exe Test.hs
"copyFile works if second argument has national path."
Test.hs: ﾆｹﾈ.txt: copyFile: does not exist (No such file or directory)
</pre><p>
System.Win32.copyFile doesn't cause this problem.
</p>
<pre class="wiki">import System.Win32
main = do
copyFile "test.txt" "テスト.txt" False -- works
print "copyFile works if second argument has national path."
copyFile "テスト.txt" "test2.txt" False -- doesn't work
print "copyFile doesn't work if second argument has national path."
copyFile "テスト.txt" "テスト2.txt" False -- doesn't work
print "copyFile doesn't work if first argument has national path."
</pre><pre class="wiki">C:\home&gt;runghc.exe Test.hs
"copyFile works if second argument has national path."
"copyFile doesn't work if second argument has national path."
"copyFile doesn't work if first argument has national path."
</pre><p>
And findExecutable return Nothing if executable file name has national symbols.
</p>
<pre class="wiki">import System.Directory -- hiding (getDirectoryContents)
main = findExecutable "テスト" &gt;&gt;= print
</pre><pre class="wiki">C:\home&gt;runghc.exe Test.hs
Nothing
</pre><p>
So, I made patch for these two problems.
</p>
Resultshttp://ghc.haskell.org/trac/ghc/ticket/3130#changeloghttp://ghc.haskell.org/trac/ghc/ticket/3436
http://ghc.haskell.org/trac/ghc/ticket/3436#3436: runtime: internal error: traverseWeakPtrList: not WEAKTue, 18 Aug 2009 09:33:03 GMTsannysanoff<p>
I was compiling my program (attached) with jhc version 0.6.1.
jhc was compiled with ghc 6.10.4 with -O, not -O2 option, as in jhc's Makefile.
ghc 6.10.4 was taken from arch linux repository.
warning: jhc compilation takes very long (I went home after 45 min) and very much (maybe 8G RAM?).
i am not sure about total memory conditions, around 10G+7G swap was available for compile.
error was:
</p>
<pre class="wiki">jhc: internal error: traverseWeakPtrList: not WEAK
(GHC version 6.10.4 for x86_64_unknown_linux)
Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug
</pre>Resultshttp://ghc.haskell.org/trac/ghc/ticket/3436#changeloghttp://ghc.haskell.org/trac/ghc/ticket/3441
http://ghc.haskell.org/trac/ghc/ticket/3441#3441: readProcess ... (exit 11): failedWed, 19 Aug 2009 13:52:27 GMTAndriy<p>
When one haskell script (here Parent.hs) runs another script (Child.hs), it fails at some point with an error:
</p>
<pre class="wiki">Parent.hs: readProcess: ./Child.hs "param1" "param2" ... "paramN" (exit 11): failed
</pre><p>
Details:
</p>
<p>
I have a set of haskell scripts. Each script has following interpreter spec as the first line:
</p>
<pre class="wiki">#!/usr/bin/env runghc
</pre><p>
These scripts manage some Java building process. Child.hs is long-running. It can run for a few hours. It builds a Java application, runs tests on it. About once a week the parent script fails with the error above. I use the script about 2-5 times a day.
</p>
<p>
My system is Ubuntu 8.04 (Hardy Heron). I installed GHC 6.10.3 locally, I also have GHC 6.8.2 installed from the Ubuntu repositories.
</p>
<p>
Besides the problem itself, it is not clear what "exit 11" means.
</p>
Resultshttp://ghc.haskell.org/trac/ghc/ticket/3441#changeloghttp://ghc.haskell.org/trac/ghc/ticket/3514
http://ghc.haskell.org/trac/ghc/ticket/3514#3514: mallocPlainForeignPtrBytes -1000 gives runtime internal error: allocGroup: requested zero blocksTue, 15 Sep 2009 19:43:01 GMTandrewbirkett<p>
Passing negative numbers to mallocPlainForeignPtrBytes causes the following to appear:
</p>
<pre class="wiki">Test: internal error: allocGroup: requested zero blocks
(GHC version 6.10.4 for i386_unknown_linux)
Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug
Aborted
</pre><p>
Originally, a bug in my app meant that I called Data.ByteString.hGet with a negative 'numBytes' argument, however I've managed to boil it down to a one line test case involving just mallocPlainForeignPtrBytes as follows:
</p>
<pre class="wiki">$ cat Test.hs
import GHC.ForeignPtr (mallocPlainForeignPtrBytes)
main = mallocPlainForeignPtrBytes (-1000)
$ ghc --make Test.hs
[1 of 1] Compiling Main ( Test.hs, Test.o )
Linking Test ...
$ ./Test
Test: internal error: allocGroup: requested zero blocks
(GHC version 6.10.4 for i386_unknown_linux)
Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug
Aborted
</pre><p>
The magnitude of the number appears to have some effect; with ghc 6.10.1 it seemed to reliably crash with numBytes &lt;= -9. But when I upgraded to ghc 6.10.4, the test case started working. However, changing to -1000 reliably causes a crash on my box - perhaps the behaviour depends on heap layout. Either way, the function should probably behave more gracefully .. perhaps raising an exception.
</p>
<p>
Full gory details of my setup (ie. ghc -v output, gcc version) are attached because they messed up the formatting.
</p>
Resultshttp://ghc.haskell.org/trac/ghc/ticket/3514#changeloghttp://ghc.haskell.org/trac/ghc/ticket/3516
http://ghc.haskell.org/trac/ghc/ticket/3516#3516: [PATCH] ppc64: broken 'foreign import wrapper'Tue, 15 Sep 2009 21:09:07 GMTslyfox<p>
Attaching simple testcase failing horribly on ppc64:
</p>
<p>
amd64 test output:
</p>
<pre class="wiki">$ ./dist/build/fct/fct
C call:[result = 105]
C call with registered C callback function:C(72)C(33)[result = 735]
C call with registered Hs-C callback function:H(72)H(33)[result = 735]
TEST PASSED
</pre><p>
ppc64 test output:
</p>
<pre class="wiki">$ dist/build/fct/fct
C call:[result = 105]
C call with registered C callback function:C(72)C(33)[result = 735]
C call with registered Hs-C callback function:[result = 105]
Segmentation fault
</pre><p>
As you see <strong>C call with registered Hs-C callback function</strong> called not a registered function, but something strange. There is no even registered callback (glo_cb == 0).
</p>
Resultshttp://ghc.haskell.org/trac/ghc/ticket/3516#changeloghttp://ghc.haskell.org/trac/ghc/ticket/3553
http://ghc.haskell.org/trac/ghc/ticket/3553#3553: parallel gc suffers badly if one thread is descheduledTue, 29 Sep 2009 13:57:53 GMTsimonmar<p>
The parallel GC synchronisation uses pure spinlocks, which leads to a severe decline in performance when one thread is descheduled. This is the main cause of the "last core parallel slowdown": using a <tt>-N</tt> value that matches the number of cores in the machine can be slower than using one fewer. The effect seems to be quite bad on Linux, reports are that it is less of an issue on OS X.
</p>
<p>
Switching to mutexes would help, but it isn't easy because we sometimes unlock these from a different thread than they were locked from, and standard mutexes don't let you do that (the locks in question are <tt>mut_spin</tt> and <tt>gc_spin</tt> in the <tt>GcThread</tt> structure).
</p>
Resultshttp://ghc.haskell.org/trac/ghc/ticket/3553#changeloghttp://ghc.haskell.org/trac/ghc/ticket/3586
http://ghc.haskell.org/trac/ghc/ticket/3586#3586: Initialisation of unboxed arrays is too slowWed, 14 Oct 2009 15:15:16 GMTsimonpj<p>
On the Clean mailing list, Philippos Apolinarius [phi500ac@…] describes a small array program (using the ST monad) that runs 400x more slowly in Haskell than Clean. I can understand a bit slower (e.g. maybe they do a better job of array-bound checks), but 400x seems large. This ticket is an invitation for someone to investigate.
</p>
<p>
He writes: I wrote a very simple program to check whether Haskell improved its array processing libraries or not. Here is how to compile and run the program arr.hs in Haskell (I have used the GHC compiler):
</p>
<pre class="wiki">&gt;ghc -O arr.hs -o arr.exe
$ time arr.exe +RTS -K32000000
2.8e8
real 0m3.938s
user 0m0.031s
sys 0m0.000s
</pre><p>
The same program in Clean:
</p>
<pre class="wiki">C:\Clean 2.2\exemplos\console&gt;arraytest.exe
280000000
Execution: 0.01 Garbage collection: 0.01 Total: 0.03
C:\Clean 2.2\exemplos\console&gt;arraytest.exe
280000000
Execution: 0.01 Garbage collection: 0.01 Total: 0.03
</pre><p>
This means that Clean is 390 times faster than Haskell in this particular problem. These results makes me worder whether Haskell is safer than Clean. It turns out that Haskell checks index out of range at runtime, exactly like Clean. Larger problems make the difference between Clean and Haskell even worse. For instance, neural networks like the one described in Schmidtt et al. run 400 times faster in Clean.
</p>
<p>
Below you will find the array examples. You can check that Clean is really much faster than Haskell. I wonder why the Benchmarks Game site does not report such a large difference between Haskell and Clean performances. I believe that people who wrote Haskell benchmarks for the Benchmarks Game site cheated in using foreign pointers to access arrays.
</p>
<pre class="wiki">-- arr.hs
import Control.Monad.ST
import Data.Array.ST
main = print $ runST
(do arr &lt;- newArray (1,2000000)
137.0 :: ST s
(STArray s
Int Double)
a &lt;- readArray arr 1
b &lt;- readArray arr 1
fn 2000000 arr 0.0 )
fn i a acc | i &lt; 1 = do (return acc)
fn i a acc= do
b &lt;- readArray a i
writeArray a i (b+3.0)
c &lt;- readArray a i
fn (i-1) a (acc+c)
</pre><p>
Clean version
</p>
<pre class="wiki">module arraytest
import StdEnv
fn i a acc | i&lt;1 = acc
fn i a=:{[i]=b} acc
# a= {a&amp;[i]= b+3.0}
# (c, a)= a![i]
= fn (i-1) a (c+acc)
Start= fn 2000000 vt 0.0
where
vt:: .{#Real}
vt = createArray 2000001 137.0
</pre>Resultshttp://ghc.haskell.org/trac/ghc/ticket/3586#changeloghttp://ghc.haskell.org/trac/ghc/ticket/3633
http://ghc.haskell.org/trac/ghc/ticket/3633#3633: Heap size suggestion of > 2145 MB gets ignoredTue, 03 Nov 2009 02:05:57 GMTtim<p>
Hello,
</p>
<p>
If I run a GHC-compiled program with:
</p>
<p>
<tt>+RTS -H2150M -RTS</tt>
</p>
<p>
or any value greater than 2150 MB, the heap size suggestion apparently gets ignored.
</p>
<p>
If there is a limit on how big the heap size suggestion can be, at least I should get an error message. My machine has 4 GB of RAM and I'm eager to use it :-)
</p>
Resultshttp://ghc.haskell.org/trac/ghc/ticket/3633#changeloghttp://ghc.haskell.org/trac/ghc/ticket/3637
http://ghc.haskell.org/trac/ghc/ticket/3637#3637: ./configure doesn't understand Gentoo's build/host/targetTue, 03 Nov 2009 23:01:08 GMTkolmodin<p>
Apparently there are several styles in how to write your build/host/target variables.
</p>
<p>
In Gentoo they look like this for my amd64 <tt>x86_64-pc-linux-gnu</tt> which doesn't play well with the current build system.
</p>
<p>
Default <tt>./configure</tt> execution in Gentoo ebuilds will pass the following flags:
</p>
<pre class="wiki">./configure --prefix=/usr --host=x86_64-pc-linux-gnu --mandir=/usr/share/man \
--infodir=/usr/share/info --datadir=/usr/share --sysconfdir=/etc \
--localstatedir=/var/lib --libdir=/usr/lib64 --build=x86_64-pc-linux-gnu
</pre><p>
Which results in:
</p>
<pre class="wiki">checking for gfind... no
checking for find... /usr/bin/find
checking for sort... /usr/bin/sort
checking for GHC version date... given 6.12.0.20091010
checking for ghc... /usr/bin/ghc
checking version of ghc... 6.10.4
Target platform inferred as: x86_64-unknown-linux
Unknown vendor linux
</pre><p>
So we sed it like this:
</p>
<pre class="wiki">build=`echo "$build" | sed -e 's/linux-gnu/linux/' -e 's/-pc-/-unknown-/'`
host=`echo "$host" | sed -e 's/linux-gnu/linux/' -e 's/-pc-/-unknown-/'`
target=`echo "$target" | sed -e 's/linux-gnu/linux/' -e 's/-pc-/-unknown-/'`
</pre><p>
but of course we would prefer not to have to handle this specially.
</p>
<p>
That is, the <tt>vendor</tt> is <tt>pc</tt> and the <tt>OS</tt> is <tt>linux-gnu</tt>.
</p>
Resultshttp://ghc.haskell.org/trac/ghc/ticket/3637#changeloghttp://ghc.haskell.org/trac/ghc/ticket/3642
http://ghc.haskell.org/trac/ghc/ticket/3642#3642: GHC does not build using the Haskell Platform on WindowsWed, 04 Nov 2009 14:47:20 GMTsimonmar<p>
We still have issues with paths containing spaces in the build system. I have fixed some of them, but there are more (that are not easy to fix). The current bug I ran into is in <tt>rules/distdir-way-opts.mk</tt> where we make the HSC2HS_OPTS by prepending --cflag/--lflag to the beginning of CC_OPTS and LD_OPTS respectively, that doesn't know where the word breaks in CC_OPTS/LD_OPTS are supposed to be.
</p>
Resultshttp://ghc.haskell.org/trac/ghc/ticket/3642#changeloghttp://ghc.haskell.org/trac/ghc/ticket/3655
http://ghc.haskell.org/trac/ghc/ticket/3655#3655: Performance regression relative to 6.10Wed, 11 Nov 2009 11:06:54 GMTsimonmar<p>
The attached program runs more slowly when compiled with 6.12 compared to 6.10. The current HEAD is also worse than 6.10, but not as bad as 6.12.
</p>
<p>
The results are below, on x86-64/Linux, first with -O:
</p>
<pre class="wiki"> time allocation
6.10.2 9.6s 6.5GB
6.12.20091011 11.0s 7.5GB
6.13.20091111 10.2s 6.2GB
</pre><p>
Interestingly, <tt>-O2</tt> makes things even worse with 6.12, but makes things slightly better with both 6.10 and 6.13:
</p>
<pre class="wiki"> time allocation
6.10.2 9.5s 6.5GB
6.12.20091011 11.8s 7.5GB
6.13.20091111 10.1s 6.2GB
</pre><p>
It may be that there is some degradation due to the new IO library, since the program generates a fair amount of output. That may account for some of the difference between 6.10.2 and 6.12/6.13, but it doesn't account for the difference between 6.12 and 6.13, which are both using the new IO library.
</p>
<p>
The program is in one module, compile with no special options. To run it:
</p>
<pre class="wiki">./pHlcm mushroom.dat 100 &gt;/dev/null +RTS -s
</pre>Resultshttp://ghc.haskell.org/trac/ghc/ticket/3655#changeloghttp://ghc.haskell.org/trac/ghc/ticket/3656
http://ghc.haskell.org/trac/ghc/ticket/3656#3656: ghci leaves /tmp/ghc* directory if killed by signalWed, 11 Nov 2009 16:12:25 GMTvvv<p>
I was wondering where do numerous /tmp/ghc${PID}_0 directories come
from. And noticed that they are not removed when I kill (close)
'*haskell*' Emacs buffer instead of typing ':q' in ghci prompt...
</p>
<p>
I've investigated this problem down to ghci: when ghci has an .hs file
<tt>:load</tt>-ed and is killed with SIGHUP or SIGTERM signal, it leaves
/tmp/ghc${PID}_0 directory.
</p>
<pre class="wiki">$ ls -d /tmp/ghc*
ls: cannot access /tmp/ghc*: No such file or directory
$ ghci *.hs &amp;
[1] 26384
$ GHCi, version 6.10.4: http://www.haskell.org/ghc/ :? for help
Loading package ghc-prim ... linking ... done.
Loading package integer ... linking ... done.
Loading package base ... linking ... done.
[1 of 1] Compiling Main ( proxy-POC.hs, interpreted )
Ok, modules loaded: Main.
*Main&gt;
$ ls -d /tmp/ghc*
/tmp/ghc26384_0
[1]+ Stopped ghci *.hs
$ kill -HUP %%
[1]+ Stopped ghci *.hs
$ ls -d /tmp/ghc*
/tmp/ghc26384_0
[1]+ Hangup ghci *.hs
$ ls -d /tmp/ghc*
/tmp/ghc26384_0
$ pgrep ghc
$ ps 26384
PID TTY STAT TIME COMMAND
</pre>Resultshttp://ghc.haskell.org/trac/ghc/ticket/3656#changeloghttp://ghc.haskell.org/trac/ghc/ticket/3677
http://ghc.haskell.org/trac/ghc/ticket/3677#3677: Optimizer creates stack overflow on filtered CAFThu, 19 Nov 2009 07:27:32 GMTjpet<p>
The following code creates a stack overflow at -O1 or -O2, when running with a moderately small stack (+RTS -K94k):
</p>
<pre class="wiki">import Data.Bits
hmm :: [Integer]
hmm = filter (\n -&gt; (n .&amp;. (n-1))==0) [1..]
main = mapM_ print hmm
</pre><p>
The lambda just picks out powers of two, so that filter will skip increasingly long subsequences. It's the filter causing the overflow.
</p>
<p>
Changing hmm to [Int], or to be let-bound, or compiling with -O0 makes the overflow go away. Using a 95k stack also makes the overflow go away. (Below 95k, stack usage is linear with the length of the filtered-out subsequence; then it seems to cap out.)
</p>
Resultshttp://ghc.haskell.org/trac/ghc/ticket/3677#changeloghttp://ghc.haskell.org/trac/ghc/ticket/3680
http://ghc.haskell.org/trac/ghc/ticket/3680#3680: Improve docs for 'length'Sun, 22 Nov 2009 20:07:21 GMTdaniel.is.fischer<p>
The haddock docs for 'length' and 'genericLength' give no indication of their complexity. This leads to many inadvertent uses of 'length', causing poor performance.
</p>
<p>
To reduce the number of those cases, I suggest inserting the complexity (/O(n)/) into the haddock docs, perhaps even a warning to the effect of "use only if you really want to know the length".
</p>
Resultshttp://ghc.haskell.org/trac/ghc/ticket/3680#changeloghttp://ghc.haskell.org/trac/ghc/ticket/3684
http://ghc.haskell.org/trac/ghc/ticket/3684#3684: Missing ghc-pkg options in --helpMon, 23 Nov 2009 19:32:01 GMTkolmodin<p>
<tt>ghc-pkg</tt> does not in <tt>--help</tt> say it can do <tt>recache</tt>.
</p>
<p>
Any other missing commands?
</p>
<p>
Could also use some trivial line-edits for the commands <tt>dot</tt> and <tt>find-module</tt>.
</p>
Resultshttp://ghc.haskell.org/trac/ghc/ticket/3684#changeloghttp://ghc.haskell.org/trac/ghc/ticket/3723
http://ghc.haskell.org/trac/ghc/ticket/3723#3723: SharedMem.hsc should include <fcntl.h>, not <sys/fcntl.h>Fri, 04 Dec 2009 01:48:46 GMTdonn<p>
libraries/unix/System/Posix/SharedMem.hsc should include &lt;fcntl.h&gt;, per POSIX 1003.1 I believe, not &lt;sys/fcntl.h&gt;
</p>
Resultshttp://ghc.haskell.org/trac/ghc/ticket/3723#changeloghttp://ghc.haskell.org/trac/ghc/ticket/3724
http://ghc.haskell.org/trac/ghc/ticket/3724#3724: rts/package.conf.d specifies -lm for all platformsFri, 04 Dec 2009 01:51:50 GMTdonn<p>
rts/package.conf.d: extra-libraries "m" ... requires -lm on all platforms, but Haiku and presumably others don't need it or support it.
</p>
Resultshttp://ghc.haskell.org/trac/ghc/ticket/3724#changeloghttp://ghc.haskell.org/trac/ghc/ticket/3726
http://ghc.haskell.org/trac/ghc/ticket/3726#3726: Internal error compiling ghc-syb-0.1.2.1Fri, 04 Dec 2009 04:18:31 GMTDavidHalperin<p>
On Ubuntu Karmic x86_64 (installed from the apt repo), when I try to compile the ghc-syb-0.1.2.1 package I get the following output:
</p>
<pre class="wiki">Building ghc-syb-0.1.2.1...
[1 of 2] Compiling GHC.SYB.Instances ( src/GHC/SYB/Instances.hs, dist/build/GHC/SYB/Instances.o )
ghc: internal error: evacuate: strange closure type 13771848
(GHC version 6.10.4 for x86_64_unknown_linux)
Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug
</pre>Resultshttp://ghc.haskell.org/trac/ghc/ticket/3726#changeloghttp://ghc.haskell.org/trac/ghc/ticket/3728
http://ghc.haskell.org/trac/ghc/ticket/3728#3728: configure should omit full path in unistd.h, stdlib.h return type testsFri, 04 Dec 2009 06:05:58 GMTdonn<p>
autoconf AC_EGREP_HEADER actually uses the C preprocessor, so include file names will be resolved properly and should not specify full (potentially wrong) path. (Wrong path on Haiku.)
</p>
Resultshttp://ghc.haskell.org/trac/ghc/ticket/3728#changeloghttp://ghc.haskell.org/trac/ghc/ticket/3730
http://ghc.haskell.org/trac/ghc/ticket/3730#3730: hp2ps: Deviation.c:(.text+0x42b): undefined reference to `sqrt'Fri, 04 Dec 2009 19:35:35 GMTslyfox<p>
Start of story is here:
<a class="ext-link" href="http://bugs.gentoo.org/show_bug.cgi?id=293208"><span class="icon">​</span>http://bugs.gentoo.org/show_bug.cgi?id=293208</a>
</p>
<p>
In short:
LIBM variable is wrongly fulfilled by test:
</p>
<pre class="wiki">configure:8389: checking for atan
configure:8389: x86_64-pc-linux-gnu-gcc -o conftest -march=nocona -O2 -pipe -Wl,-O1 conftest.c -lbfd -liberty &gt;&amp;5
conftest.c:109: warning: conflicting types for built-in function 'atan'
configure:8389: $? = 0
</pre><p>
thus test leads to
</p>
<pre class="wiki">LIBM=''
</pre><p>
, then that sole LIBM passed to hp2ps and hp2ps fails, as no -lbfd -liberty were passed:
</p>
<pre class="wiki">gcc -o hp2ps -O -march=native -O2 -pipe -Wa,--noexecstack -I../../includes
-Wall AreaBelow.o AuxFile.o Axes.o Curves.o Deviation.o Dimensions.o
Error.o HpFile.o Key.o Main.o Marks.o PsFile.o Reorder.o Scale.o Shade.o
TopTwenty.o TraceElement.o Utilities.o
Deviation.o: In function `Deviation':
Deviation.c:(.text+0x42b): undefined reference to `sqrt'
</pre><p>
AFAIU, before testing for atan presence in -lm ghc should hide his previously found $LIBS, as LIBM is planned to be used separately.
</p>
<p>
And separate issue:
hp2ps (and other utils/) does not seem to respect external LDFLAGS
</p>
<p>
some spam on #ghc (nothing new):
</p>
<pre class="wiki">21:02:36 &lt; trofi&gt; hi, i seem to have found small bunch of bugs in ghc-6.10.4/ghc-6.12
21:03:32 &lt; trofi&gt; I don't like how LIBM variable is detected. It leads to bugs like
http://bugs.gentoo.org/show_bug.cgi?id=293208
21:04:41 &lt; trofi&gt; first test finds atan in absolutely unrelated libs: configure:17837: /usr/bin/gcc -o conftest -g -O2
conftest.c -lbfd -liberty &gt;&amp;5
21:04:49 &lt; trofi&gt; and decides LIBM=''
21:06:13 &lt; trofi&gt; is it standard autotools practice to grind libraries together?
21:06:36 &lt; trofi&gt; i thought they should be tested separately
21:09:21 &lt; pejo&gt; trofi, so in what library is atan on your OS?
21:10:19 &lt; trofi&gt; libm
21:10:53 &lt; trofi&gt; the problem is autoconf tests not only libm, but libs he found before: -lbfd and -liberty
21:13:04 &lt; trofi&gt; (at a time)
21:13:12 &lt; pejo&gt; What autoconf tests depends on how you've written your tests. If it finds atan in either libiberty or libbdf,
then it doesn't need libm, does it?
21:13:32 &lt; trofi&gt; yes it doesn't
21:13:49 &lt; trofi&gt; but ghc build system does not pass those libraries to build some utils
21:13:55 &lt; trofi&gt; it passes only LIBM
21:14:11 &lt; trofi&gt; which is "obviously" empty
21:14:55 &lt; trofi&gt; it's another bug - when some utils are built there is no respect of user's LDFLAGS variable
</pre><p>
Sorry for describing bug in reverse order.
Seems like ghc-6.12 is affected too.
</p>
Resultshttp://ghc.haskell.org/trac/ghc/ticket/3730#changeloghttp://ghc.haskell.org/trac/ghc/ticket/3741
http://ghc.haskell.org/trac/ghc/ticket/3741#3741: ghci misinterprets "early" unicode charactersThu, 10 Dec 2009 08:26:43 GMTbrian<p>
It seems as if ghci misinterprets unicode characters if they occur too early in a source file.
</p>
<pre class="wiki">$ cat test.hs
--data A = A -- example will not work if this line is commented
笑 :: [a] -&gt; Int
笑 = length
</pre><pre class="wiki">$ ghci test.hs
GHCi, version 6.10.4: http://www.haskell.org/ghc/ :? for help
Loading package ghc-prim ... linking ... done.
Loading package integer ... linking ... done.
Loading package base ... linking ... done.
[1 of 1] Compiling Main ( test.hs, interpreted )
test.hs:2:0:
Illegal signature in pattern: [a] -&gt; Int 笑
Use -XScopedTypeVariables to permit it
Failed, modules loaded: none.
Prelude&gt;
</pre><p>
Uncommenting the first line makes the problem go away.
</p>
Resultshttp://ghc.haskell.org/trac/ghc/ticket/3741#changeloghttp://ghc.haskell.org/trac/ghc/ticket/3742
http://ghc.haskell.org/trac/ghc/ticket/3742#3742: redundant space in FFI imports rejected by 6.12Thu, 10 Dec 2009 11:33:09 GMTduncan<p>
GHC 6.10 and older accepted this code:
</p>
<pre class="wiki">foreign import ccall unsafe " g_get_application_name"
g_get_application_name :: (IO (Ptr CChar))
</pre><p>
GHC 6.12 now rejects it with
</p>
<pre class="wiki">glib/System/Glib/Utils.chs:81:28: Malformed entity string
</pre><p>
The problem is the leading space in the C entity string. This code is generated by c2hs which is doing <tt>header ++ " " ++ ident</tt> however the header may be empty.
</p>
<p>
We should probably allow this code, though possibly with a warning. In parallel, c2hs could be fixed so it doesn't do that.
</p>
Resultshttp://ghc.haskell.org/trac/ghc/ticket/3742#changeloghttp://ghc.haskell.org/trac/ghc/ticket/3745
http://ghc.haskell.org/trac/ghc/ticket/3745#3745: Non-deterministic behavior with FFIFri, 11 Dec 2009 10:44:26 GMTgchrupala<p>
I have a simple perceptron learning algorithm in C++ which I am calling from Haskell via FFI. Most of the time it works perfectly, but occasionally the results it produces are not the expected. It seems to happen more often if there is another memory/cpu intensive process running on the machine.
</p>
<p>
The same never happens when I call the same function from C++, which seems to indicate the problem is related to GHC.
</p>
<p>
I attach a simplified extract of the code which will show the problem.
</p>
<p>
I included:
</p>
<ul><li>c_perceptronmodel.cpp, c_perceptronmodel.h : C++ implementation
</li></ul><ul><li>test.hs : Haskell program which calls the C++ function via FFI
</li></ul><ul><li>test.cpp : Equivalent C++ program which calls the same C++ function
</li></ul><ul><li>run.sh : shell script which will repeatedly run a program and check if any consecutive two runs produce different results
</li></ul><ul><li>train : data file which the programs process
</li></ul><p>
I compiled using GHC 6.10.4 like this:
</p>
<pre class="wiki">ghc-6.10.4 --make -O2 -o test-ghc-6.10.4 test.hs c_perceptronmodel.cpp -lstdc++
</pre><p>
To see the problem execute:
</p>
<pre class="wiki">./run.sh ./test-ghc-6.10.4
</pre>Resultshttp://ghc.haskell.org/trac/ghc/ticket/3745#changeloghttp://ghc.haskell.org/trac/ghc/ticket/3748
http://ghc.haskell.org/trac/ghc/ticket/3748#3748: Bug in rts/Win32/Ticker.c can cause process hang on exit in Win32Sat, 12 Dec 2009 14:02:56 GMTsgf<p>
On Win32, the ticker thread is shut down by signalling for it to close, waiting 20ms, and then calling TerminateThread if it hasn't already terminated. On a heavily-loaded system, the 20ms timeout can be exceeded, and TerminateThread is called. There is then a race condition. According to our tests, in about 1 in 100 calls to TerminateThread, the ticker thread is holding the Windows loader lock (which is held during parts of thread shutdown). It is killed holding the lock, and no other thread can acquire the lock. Therefore, no other thread can die, and the whole process hangs on exit.
</p>
<p>
Isn't the Win32 API lovely?
</p>
<p>
Given the timeout occurs about 1 in 100 times on a heavily-loaded box (more runnable threads than cores), and then the hang occurs on 1 in 100 timeouts, it's a slightly tedious bug to reproduce. My test case was 4 shell windows in infinite loops running a small GHC executable that forces the ticker thread to be started by using System.Timeout.timeout.
</p>
<p>
My suggestions:
</p>
<p>
As the code suggests, if the ticker is compiled into a DLL, the thread must die before the DLL can be safely unloaded - otherwise an unhandled exception will wreak havoc in the process. The best suggestion I can think of is to increase the timeout, to 200ms say. After all, the timeout should rarely be reached except on heavily loaded systems, few people need a guaranteed quick response time on DLL unload, and any time the timeout is hit we introduce the possibility of basically breaking the process when we call TerminateThread.
</p>
<p>
For the runtime compiled into an executable, there is no need to call TerminateThread. The executable will remain mapped until after the ticker thread is forcibly terminated by the Windows system. Instead, we can simply attempt to signal the thread to close, wait for a timeout, and then shrug our shoulders and return, giving the least-unclean program shutdown possible in that case.
</p>
<p>
If people are happy with my proposed changes, I can make a patch.
</p>
Resultshttp://ghc.haskell.org/trac/ghc/ticket/3748#changeloghttp://ghc.haskell.org/trac/ghc/ticket/3751
http://ghc.haskell.org/trac/ghc/ticket/3751#3751: Panic! the 'impossible' happened: charType: '\167'Mon, 14 Dec 2009 11:12:06 GMTmoleculeColony<p>
Reproduces each time:
</p>
<pre class="wiki">Prelude&gt; "\§"
ghc: panic! (the 'impossible' happened)
(GHC version 6.10.4 for x86_64-unknown-linux):
charType: '\167'
Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug
</pre>Resultshttp://ghc.haskell.org/trac/ghc/ticket/3751#changeloghttp://ghc.haskell.org/trac/ghc/ticket/3759
http://ghc.haskell.org/trac/ghc/ticket/3759#3759: -no-auto-link-packages flag isn't documented in User GuideTue, 15 Dec 2009 22:18:27 GMThgolden<p>
The -no-auto-link-packages flag (see compiler/main/DynFlags.hs) isn't documented in the User Guide.
</p>
Resultshttp://ghc.haskell.org/trac/ghc/ticket/3759#changeloghttp://ghc.haskell.org/trac/ghc/ticket/3760
http://ghc.haskell.org/trac/ghc/ticket/3760#3760: 6.12.1 Build failure on FreeBSDWed, 16 Dec 2009 03:41:43 GMTPHO<p>
I found 6.12.1's rts/posix/Select.c doesn't compile on FreeBSD 7.0.
It uses "fd_set" which is defined by sys/select.h, but Select.c doesn't #include it.
So I put "#include &lt;sys/select.h&gt;" at the beginning of Select.c, then the problem went away.
</p>
<p>
(Sorry for not pasting any build log. I forgot to capture it.)
</p>
Resultshttp://ghc.haskell.org/trac/ghc/ticket/3760#changeloghttp://ghc.haskell.org/trac/ghc/ticket/3761
http://ghc.haskell.org/trac/ghc/ticket/3761#3761: 6.12.1 HC bootstrap failes due to suspicious static library orderingWed, 16 Dec 2009 04:04:53 GMTPHO<p>
I found ghc-stage2 doesn't link because of the order of static libraries passed to gcc. The problem occurs on FreeBSD but I believe it's platform-independent.
</p>
<p>
The build system puts rts/dist/build/libHSrts.a followed by rts/dist/build/libHSrtsmain.a. The latter has an undefined symbol to "hs_main" which is defined in libHSrts.a, so the linker complains about the absence of hs_main.
</p>
<p>
The following patch to rts/ghc.mk solves the problem:
</p>
<pre class="wiki">--- ghc.mk.orig 2009-12-11 03:11:33.000000000 +0900
+++ ghc.mk
@@ -19,8 +19,9 @@ rts_dist_HC = $(GHC_STAGE1)
# merge GhcLibWays and GhcRTSWays but strip out duplicates
rts_WAYS = $(GhcLibWays) $(filter-out $(GhcLibWays),$(GhcRTSWays))
-ALL_RTS_LIBS = $(foreach way,$(rts_WAYS),rts/dist/build/libHSrts$($(way)_libsuf)) \
- rts/dist/build/libHSrtsmain.a
+ALL_RTS_LIBS = rts/dist/build/libHSrtsmain.a \
+ $(foreach way,$(rts_WAYS),rts/dist/build/libHSrts$($(way)_libsuf))
+
all_rts : $(ALL_RTS_LIBS)
# -----------------------------------------------------------------------------
</pre>Resultshttp://ghc.haskell.org/trac/ghc/ticket/3761#changeloghttp://ghc.haskell.org/trac/ghc/ticket/3762
http://ghc.haskell.org/trac/ghc/ticket/3762#3762: filepath.cabal has an extraneous apostropheWed, 16 Dec 2009 06:23:00 GMTohnobinki<p>
<a class="ext-link" href="https://bugs.gentoo.org/296699"><span class="icon">​</span>https://bugs.gentoo.org/296699</a>
</p>
Resultshttp://ghc.haskell.org/trac/ghc/ticket/3762#changeloghttp://ghc.haskell.org/trac/ghc/ticket/3764
http://ghc.haskell.org/trac/ghc/ticket/3764#3764: need --htmldir conifigurationWed, 16 Dec 2009 07:57:28 GMTjuhpetersen<p>
ghc's makefiles currently ignore --htmldir overriding it to $(docdir)/html:
this is also noted in comments for autoconf .backward compatibility.
</p>
<p>
Since only html is generated by default distro packagers probably prefer to drop
the html/ subdir and just install the html docs straight to docdir.
Having a working --htmldir configure options would allow this without
fragile build hacks.
</p>
Resultshttp://ghc.haskell.org/trac/ghc/ticket/3764#changeloghttp://ghc.haskell.org/trac/ghc/ticket/3768
http://ghc.haskell.org/trac/ghc/ticket/3768#3768: 6.12.1 Mac OS X installer lacks all HTML documentationWed, 16 Dec 2009 22:07:39 GMTMinimiscience<p>
After upgrading GHC from 6.10.4 to 6.12.1 using the installer package for Mac OS X Leopard, I found that the local HTML documentation (aside from moving from <tt>/usr/share/doc/ghc/index.html</tt> to <tt>/usr/share/doc/ghc/html/index.html</tt>) was lacking a few parts. Specifically, the links to the user's guide, GHC API, and Cabal no longer lead to extant documents, and I was unable to find the documents that they should link to anywhere in the <tt>/Library/Frameworks/GHC.framework/Versions</tt> directory. The only local link that still works is the link to the library documentation, and its index page still lists some modules that are no longer distributed with the current version of GHC (specifically, the mtl package, though there may be others that I haven't come across).
</p>
<p>
This was observed on Mac OS X 10.5.8 with gcc 4.0.1, though it may or may not also apply to other systems.
</p>
Resultshttp://ghc.haskell.org/trac/ghc/ticket/3768#changeloghttp://ghc.haskell.org/trac/ghc/ticket/3770
http://ghc.haskell.org/trac/ghc/ticket/3770#3770: getting docs out of windows distroThu, 17 Dec 2009 09:07:45 GMTdenis<p>
Would you be so kind as to split the _windows_ distribution into binary, mingw, and doc packages? The doc distribution is bloated intolerably. You see, if one wants to upgrade the binary, one also has to reinstall 370 MiB of tiny html stuff that could be found online, for example...
</p>
Resultshttp://ghc.haskell.org/trac/ghc/ticket/3770#changeloghttp://ghc.haskell.org/trac/ghc/ticket/3773
http://ghc.haskell.org/trac/ghc/ticket/3773#3773: Haddoc documentation on wrong function argumentSat, 19 Dec 2009 16:17:33 GMTtibbe<p>
The catch function's documentation indicates that the first parameter is the exception handler when it in reality is the second.
</p>
<p>
<a href="http://www.haskell.org/ghc/docs/latest/html/libraries/base-4.2.0.0/Control-Exception.html#5">http://www.haskell.org/ghc/docs/latest/html/libraries/base-4.2.0.0/Control-Exception.html#5</a>
</p>
Resultshttp://ghc.haskell.org/trac/ghc/ticket/3773#changeloghttp://ghc.haskell.org/trac/ghc/ticket/3776
http://ghc.haskell.org/trac/ghc/ticket/3776#3776: Warning: The import of `B.foo' from module `A' is redundantSun, 20 Dec 2009 21:25:37 GMTslyfox<p>
Let's consider such <strong>A.hs</strong>:
</p>
<pre class="wiki">module A (C(foo)) where
class C a where
foo :: a
foo = bar
bar :: a
bar = foo
</pre><p>
and <strong>B.hs</strong>:
</p>
<pre class="wiki">module B (Foo(..)) where
import qualified A as B (C(foo))
-- import qualified A as B (C) -- ? erros too
data Foo = Foo Int deriving Show
instance B.C Foo where
foo = Foo 4
</pre><p>
Trying to build:
</p>
<pre class="wiki">$ ghc --make -Wall -Werror B
[1 of 2] Compiling A ( A.hs, A.o )
[2 of 2] Compiling B ( B.hs, B.o )
B.hs:3:0:
Warning: The import of `B.foo' from module `A' is redundant
&lt;no location info&gt;:
Failing due to -Werror.
</pre><p>
If I will remove foo somehow - I will get another error.
At least message looks misleading, and warning seems to be false positive.
</p>
<p>
Might be related ot <a class="closed ticket" href="http://ghc.haskell.org/trac/ghc/ticket/1074" title="bug: -fwarn-unused-imports complains about wrong import (closed: fixed)">#1074</a>
</p>
Resultshttp://ghc.haskell.org/trac/ghc/ticket/3776#changeloghttp://ghc.haskell.org/trac/ghc/ticket/3778
http://ghc.haskell.org/trac/ghc/ticket/3778#3778: "test -e" in testsuite doesn't work with Solaris /bin/shMon, 21 Dec 2009 17:31:15 GMTduncan<p>
The <tt>testsuite/mk/boilerplate.mk</tt> contains stuff like:
</p>
<pre class="wiki">$(eval $(call canonicaliseExecutable,TEST_HC))
ifeq "$(shell test -e '$(TEST_HC)' &amp;&amp; echo exists)" ""
$(error Cannot find ghc: $(TEST_HC))
endif
</pre><p>
On Solaris, the <tt>/bin/sh</tt> test builtin does not support the <tt>-e</tt> flag. It does support both <tt>-f</tt> and <tt>-x</tt>, meaning regular and executable file respectively. I think we probably mean <tt>-x</tt> in this case anyway. With that fix the testsuite seems to run ok.
</p>
<p>
Looks like we already use <tt>test -x</tt> elsewhere in <tt>testsuite/mk/boilerplate.mk</tt> so we can assume that it does work with the shell of other platforms.
</p>
Resultshttp://ghc.haskell.org/trac/ghc/ticket/3778#changeloghttp://ghc.haskell.org/trac/ghc/ticket/3780
http://ghc.haskell.org/trac/ghc/ticket/3780#3780: unix-2.4.0.0 fails with base 4.1Tue, 22 Dec 2009 11:12:16 GMTduncan<p>
The unix package states:
</p>
<pre class="wiki">build-depends: base &gt;=4.1 &amp;&amp; &lt;4.3
</pre><p>
And while it does compile with base 4.1, using ghc-6.10, nothing can successfully link against it.
</p>
<p>
The symptoms are:
</p>
<pre class="wiki">/usr/lib64/ghc-6.10.4/base-4.1.0.0/libHSbase-4.1.0.0.a(PrelIOUtils.o): In function `__hscore_d_name':
(.text+0x1c0): multiple definition of `__hscore_d_name'
/home/duncan/.cabal/lib/unix-2.4.0.0/ghc-6.10.4/libHSunix-2.4.0.0.a(dirUtils.o):dirUtils.c:(.text+0x0): first defined here
/usr/lib64/ghc-6.10.4/base-4.1.0.0/libHSbase-4.1.0.0.a(PrelIOUtils.o): In function `__hscore_free_dirent':
(.text+0x4f0): multiple definition of `__hscore_free_dirent'
/home/duncan/.cabal/lib/unix-2.4.0.0/ghc-6.10.4/libHSunix-2.4.0.0.a(dirUtils.o):dirUtils.c:(.text+0x10): first defined here
/home/duncan/.cabal/lib/unix-2.4.0.0/ghc-6.10.4/libHSunix-2.4.0.0.a(IO.o): In function `sk63_info':
(.text+0x30c4): undefined reference to `fcntl_read'
/home/duncan/.cabal/lib/unix-2.4.0.0/ghc-6.10.4/libHSunix-2.4.0.0.a(IO.o): In function `sk6A_info':
(.text+0x31f0): undefined reference to `fcntl_write'
/home/duncan/.cabal/lib/unix-2.4.0.0/ghc-6.10.4/libHSunix-2.4.0.0.a(IO.o): In function `sk8h_info':
(.text+0x36cc): undefined reference to `fcntl_read'
/home/duncan/.cabal/lib/unix-2.4.0.0/ghc-6.10.4/libHSunix-2.4.0.0.a(IO.o): In function `sl4O_info':
(.text+0x3a52): undefined reference to `fcntl_lock'
/home/duncan/.cabal/lib/unix-2.4.0.0/ghc-6.10.4/libHSunix-2.4.0.0.a(IO.o): In function `sl6S_info':
(.text+0x3cc2): undefined reference to `fcntl_lock'
/home/duncan/.cabal/lib/unix-2.4.0.0/ghc-6.10.4/libHSunix-2.4.0.0.a(IO.o): In function `sl9I_info':
(.text+0x402a): undefined reference to `fcntl_lock'
</pre><p>
There are two problems here, the duplicate <tt>__hscore_*</tt> symbols and and the missing <tt>fcntl_*</tt> symbols.
</p>
<p>
The <tt>__hscore_d_name</tt> C function really is duplicated. There is one copy in <tt>base/include/HsBase.h</tt> in ghc-6.10, there is another copy in <tt>cbits/dirUtils.c</tt> in unix-2.4.0.0. Clearly what has happened is that the function from base has been moved into the unix package. However that means when building the unix package with the older base then we get both. The solution is to rename the one in the unix package. Ideally we could limit the visibility of symbols somehow.
</p>
<p>
The <tt>fcntl_read</tt> are not defined in the unix package. They are defined in <tt>HsBase.h</tt> in ghc-6.12 but not in 6.10. Hence they are also missing when unix-2.4.0.0 is built against the older base. The solution is to define them locally.
</p>
<p>
Originally filed as Cabal ticket: <a class="ext-link" href="http://hackage.haskell.org/trac/hackage/ticket/620"><span class="icon">​</span>http://hackage.haskell.org/trac/hackage/ticket/620</a>
</p>
Resultshttp://ghc.haskell.org/trac/ghc/ticket/3780#changeloghttp://ghc.haskell.org/trac/ghc/ticket/3784
http://ghc.haskell.org/trac/ghc/ticket/3784#3784: --with-gmp-includes and --with-gmp-libraries don't affect the building process of integer-gmp/cbits/mkGmpDerivedConstantsThu, 24 Dec 2009 02:35:59 GMTPHO<p>
Passing --with-gmp-includes and --with-gmp-libraries to the libraries/integer-gmp/configure doesn't affect the building process of cbits/mkGmpDerivedConstants:
</p>
<pre class="wiki">"/usr/bin/gcc" libraries/integer-gmp/cbits/mkGmpDerivedConstants.c -o libraries/integer-gmp/cbits/mkGmpDerivedConstants
libraries/integer-gmp/cbits/mkGmpDerivedConstants.c:15:17: error: gmp.h: No such file or directory
</pre><p>
I could solve this problem by appendding the following line to libraries/integer-gmp/gmp/config.mk.in but I'm not sure this is the best way:
</p>
<pre class="wiki">libraries/integer-gmp_CC_OPTS += @CPPFLAGS@ @LDFLAGS@
</pre>Resultshttp://ghc.haskell.org/trac/ghc/ticket/3784#changeloghttp://ghc.haskell.org/trac/ghc/ticket/3785
http://ghc.haskell.org/trac/ghc/ticket/3785#3785: Broken link in library docsThu, 24 Dec 2009 14:11:39 GMTigloo<p>
We need to generate <tt>libraries/prologue.txt</tt> with the version number in the link now that packages include their version number.
</p>
Resultshttp://ghc.haskell.org/trac/ghc/ticket/3785#changeloghttp://ghc.haskell.org/trac/ghc/ticket/3788
http://ghc.haskell.org/trac/ghc/ticket/3788#3788: Improved message for GHC "No instance for" ErrorsSat, 26 Dec 2009 17:49:28 GMTrhapsodyv<p>
Hi,
</p>
<p>
I would like to propose a modification in the ghc message for "no
instance for" errors.
In the message, the ghc tells that there's no instance for the type
you are using and it give you a hint that you can fix it adding a new
instance for your type. But it don't tell me any instance alternative
that already exists. So, if I don't know the correct type, I need to
look at the documentation.
</p>
<p>
At least for me, I get this message when I'm using the function in the
wrong way or when I forget to specify the some function signature.
It's quite rare the I want to add a new instance.
Of course that it's not a problem to look at the documentation, but
improving it can save a significant time and help the beginers to
guess the error and how fix it.
</p>
<p>
In C++ and Java, when I use g++ or javac and I make a wrong
overloading, the compiler show me some alternatives. I think it help
more than tell me to add a new overload to the function.
</p>
<p>
It's possible to do it in ghc?
</p>
Resultshttp://ghc.haskell.org/trac/ghc/ticket/3788#changeloghttp://ghc.haskell.org/trac/ghc/ticket/3789
http://ghc.haskell.org/trac/ghc/ticket/3789#3789: Segfault and -dstg-lint errors using FFI and -XEmptyDataDeclsSat, 26 Dec 2009 19:26:31 GMTjudahj<p>
I encountered a segfault when working with some FFI code. I eventually discovered that this code also makes <tt>-dstg-lint</tt> complain.
</p>
<p>
With the below files, I can reproduce the segfault and <tt>-dstg-lint</tt> issues using ghc-6.12.1 and ghc-6.10.3 on OS X 10.6.2. The segfault goes away if I use -fvia-C, -O, or if I build on OS X 10.5.7.
</p>
<p>
The segfault also goes away if I use a unit type <tt>()</tt> instead of -XEmptyDataDecls.
</p>
<pre class="wiki">$ ghc --make test-segfault.hs foreign.c -XForeignFunctionInterface \
-XEmptyDataDecls -fforce-recomp &amp;&amp; ./test-segfault
[1 of 2] Compiling Types ( Types.hs, Types.o )
[2 of 2] Compiling Main ( test-segfault.hs, test-segfault.o )
Linking test-segfault ...
About to create...
Segmentation fault
</pre><p>
foreign.c:
</p>
<pre class="wiki">#include &lt;stdio.h&gt;
#include &lt;stdlib.h&gt;
void *
c_createFoo (int x) {
fprintf(stderr,"Creating foo...\n");
fflush(stderr);
int *p = malloc(sizeof(int));
*p = x;
return p;
}
</pre><p>
Types.hs:
</p>
<pre class="wiki">module Types where
import Foreign.Ptr
import Foreign.C.Types
-- Replacing this line with the following one prevents the segfault,
-- but not the -dstg-lint error.
data Foo_
-- type Foo_ = ()
foreign import ccall safe c_createFoo :: CInt -&gt; IO (Ptr Foo_)
createFoo :: Int -&gt; IO (Ptr Foo_)
createFoo dtype = c_createFoo (toEnum dtype)
</pre><p>
test-segfault.hs:
</p>
<pre class="wiki">module Main where
import Types
main = do
putStrLn "About to create..."
createFoo 1
putStrLn "Created."
</pre><p>
The <tt>-dstg-lint</tt> error is somewhat long, but I can paste it if you're unable to reproduce it.
</p>
Resultshttp://ghc.haskell.org/trac/ghc/ticket/3789#changeloghttp://ghc.haskell.org/trac/ghc/ticket/3790
http://ghc.haskell.org/trac/ghc/ticket/3790#3790: control-C causes segfault, siginfo_t* can be NULL on SolarisMon, 28 Dec 2009 00:03:53 GMTduncan<p>
On Sparc Solaris, all ghc-compiled programs (including ghc and ghci) segfault when interrupted with control-C.
</p>
<p>
This happens with ghc-6.10.4 and 6.12.1. It worked OK in ghc-6.8.3.
</p>
<p>
The following is a gdb backtrace generated from a core file produced from running ghc-6.12.1 and hitting <sup>C.
</sup></p>
<pre class="wiki">#0 0xff0b05d4 in memcpy ()
from /platform/SUNW,SPARC-Enterprise-T5120/lib/libc_psr.so.1
#1 0x01d17040 in generic_handler ()
#2 &lt;signal handler called&gt;
#3 0xff1c4a34 in __lwp_park () from /lib/libc.so.1
#4 0xff1be968 in cond_sleep_queue () from /lib/libc.so.1
#5 0xff1bea84 in cond_wait_queue () from /lib/libc.so.1
#6 0xff1bf004 in cond_wait () from /lib/libc.so.1
#7 0xff1bf040 in pthread_cond_wait () from /lib/libc.so.1
#8 0x01d16ab0 in waitCondition ()
#9 0x01d01058 in yieldCapability ()
#10 0x01d07c08 in schedule ()
#11 0x01d055e4 in real_main ()
#12 0x01d0578c in hs_main ()
#13 0x00515434 in _start ()
</pre><p>
The backtrace from a trivial ghc-compiled program looks similar. The only interesting thing this tells us is that the problem happens with the single-threaded and multi-threaded RTSs similarly.
</p>
<p>
Looking at <tt>generic_handler</tt> in <tt>./posix/Signals.c</tt>, in the <tt>defined(THREADED_RTS)</tt> case:
</p>
<pre class="wiki"> StgWord8 buf[sizeof(siginfo_t) + 1];
int r;
buf[0] = sig;
memcpy(buf+1, info, sizeof(siginfo_t));
</pre><p>
and in the <tt>! defined(THREADED_RTS)</tt>:
</p>
<pre class="wiki">memcpy(next_pending_handler, info, sizeof(siginfo_t));
</pre><p>
So it would appear that the <tt>siginfo_t *info</tt> parameter to <tt>generic_handler</tt> is NULL.
</p>
<p>
The Solaris manpage for <tt>sigaction</tt> indicates that the <tt>siginfo_t</tt> pointer may be NULL. Presumably it is non-NULL for the kind of signals that have extra info, like <tt>SIGCHILD</tt>, but not for <tt>SIGINT</tt>. The manpage for <tt>siginfo.h</tt> lists a number of kinds of signals that do receive a <tt>siginfo_t</tt> but <tt>SIGINT</tt> is not amongst them.
</p>
<p>
So this would explain why it worked in 6.8.3, since we only started using the <tt>siginfo_t *</tt> in 6.10.
</p>
<p>
So I guess we either push a "null"/"empty" <tt>siginfo_t</tt> down the IO manager pipe, or provide a way to indicate that there is no <tt>siginfo_t</tt> supplied.
</p>
Resultshttp://ghc.haskell.org/trac/ghc/ticket/3790#changeloghttp://ghc.haskell.org/trac/ghc/ticket/3792
http://ghc.haskell.org/trac/ghc/ticket/3792#3792: Qualified names in import specificationsMon, 28 Dec 2009 12:24:34 GMTnibro<p>
GHC accepts qualified names in import specifications, e.g.
</p>
<pre class="wiki">module Main where
import Foo (Bar.bar)
</pre><p>
I don't see the point of this, nor is it documented anywhere. I propose that either a) this (mis)feature is removed, or b) this feature is documented and tied to a registered extension that can be enabled or disabled as seen fit.
</p>
Resultshttp://ghc.haskell.org/trac/ghc/ticket/3792#changeloghttp://ghc.haskell.org/trac/ghc/ticket/3793
http://ghc.haskell.org/trac/ghc/ticket/3793#3793: System.Time.toClockTime does not support all valid timezone offsets.Mon, 28 Dec 2009 22:20:35 GMTdaniel<p>
toClockTime errors when the timezone offset is outside the range of -1200 to +1200. There are valid timezone offsets greater than +1200. Parts of Kiribati are, I believe, +1400.
</p>
<p>
Attached is a patch against the current head.
</p>
Resultshttp://ghc.haskell.org/trac/ghc/ticket/3793#changeloghttp://ghc.haskell.org/trac/ghc/ticket/3794
http://ghc.haskell.org/trac/ghc/ticket/3794#3794: Compiling a main program yields: /usr/bin/ld: cannot find -lHSrtsmainTue, 29 Dec 2009 02:42:38 GMTguest<p>
I have installed the generic Linux binary package for GHC-6.12.1 from
</p>
<blockquote>
<p>
<a href="http://www.haskell.org/ghc/dist/6.12.1/ghc-6.12.1-i386-unknown-linux-n.tar.bz2">http://www.haskell.org/ghc/dist/6.12.1/ghc-6.12.1-i386-unknown-linux-n.tar.bz2</a>
</p>
</blockquote>
<p>
on Kubuntu.
</p>
<p>
When I try to compile a simple main program, like
</p>
<pre class="wiki">main = putStr "Hello world!\n"
</pre><p>
I get
</p>
<pre class="wiki">/usr/bin/ld: cannot find -lHSrtsmain
</pre><p>
The reason is, that <tt>/usr/local/lib/ghc-6.12.1/libHSrtsmain.a</tt> is not readable by users.
I could fix the problem for me using
</p>
<pre class="wiki">sudo chmod a+r /usr/local/lib/ghc-6.12.1/libHS*
</pre>Resultshttp://ghc.haskell.org/trac/ghc/ticket/3794#changeloghttp://ghc.haskell.org/trac/ghc/ticket/3796
http://ghc.haskell.org/trac/ghc/ticket/3796#3796: GHC 6.12 dependency checking many times slower than 6.10Thu, 31 Dec 2009 14:38:36 GMTsunrayser<p>
Get feldspar-language-0.1 from hackage and build it:
</p>
<p>
<a class="ext-link" href="http://hackage.haskell.org/package/feldspar-language"><span class="icon">​</span>http://hackage.haskell.org/package/feldspar-language</a>
</p>
<p>
<a class="ext-link" href="http://hackage.haskell.org/packages/archive/feldspar-language/0.1/feldspar-language-0.1.tar.gz"><span class="icon">​</span>http://hackage.haskell.org/packages/archive/feldspar-language/0.1/feldspar-language-0.1.tar.gz</a>
</p>
<p>
Performance:
</p>
<pre class="wiki">"cabal configure; cabal cuild; time cabal build"
6.12:
real 0m24.316s
user 0m24.063s
sys 0m0.159s
6.10:
real 0m2.252s
user 0m2.021s
sys 0m0.231s
"time cabal build" with 6.10 after "cabal build"-ing it with 6.12 (ie no "rm -rf dist" before building with 6.10)
real 0m24.304s
user 0m24.094s
sys 0m0.139s
</pre><p>
The last one is especially strange.
</p>
Resultshttp://ghc.haskell.org/trac/ghc/ticket/3796#changeloghttp://ghc.haskell.org/trac/ghc/ticket/3799
http://ghc.haskell.org/trac/ghc/ticket/3799#3799: undefined symbols and undefined references possibly related to template haskellFri, 01 Jan 2010 17:15:21 GMTJeremyShaw<p>
I have seen a number of instances where template-haskell (?) fails at compile time due to missing symbols. For example, when building happstack-data:
</p>
<pre class="wiki">&gt; [ 7 of 16] Compiling Happstack.Data.Xml.Base (
&gt; src/Happstack/Data/Xml/Base.hs, dist/build/Happstack/Data/Xml/Base.o )
&gt; Loading package ghc-prim ... linking ... done.
&gt; Loading package integer-gmp ... linking ... done.
&gt; Loading package base ... linking ... done.
&gt; Loading package array-0.3.0.0 ... linking ... done.
&gt; Loading package bytestring-0.9.1.5 ... linking ... done.
&gt; Loading package containers-0.3.0.0 ... linking ... done.
&gt; Loading package pretty-1.0.1.1 ... linking ... done.
&gt; Loading package template-haskell ... linking ... done.
&gt; Loading package syb-with-class-0.6.1 ... linking ... done.
&gt; Loading package HUnit-1.2.2.1 ... linking ... done.
&gt; Loading package syb-0.1.0.2 ... linking ... done.
&gt; Loading package base-3.0.3.2 ... linking ... done.
&gt; Loading package old-locale-1.0.0.2 ... linking ... done.
&gt; Loading package time-1.1.4 ... linking ... done.
&gt; Loading package random-1.0.0.2 ... linking ... done.
&gt; Loading package QuickCheck-1.2.0.0 ... linking ... done.
&gt; Loading package extensible-exceptions-0.1.1.1 ... linking ... done.
&gt; Loading package mtl-1.1.0.2 ... linking ... done.
&gt; Loading package old-time-1.0.0.3 ... linking ... done.
&gt; Loading package parsec-2.1.0.1 ... linking ... done.
&gt; Loading package hsemail-1.3 ... linking ... done.
&gt; Loading package network-2.2.1.5 ... linking ... done.
&gt; Loading package SMTPClient-1.0.1 ... linking ... done.
&gt; Loading package filepath-1.1.0.3 ... linking ... done.
&gt; Loading package unix-2.4.0.0 ... linking ... done.
&gt; Loading package directory-1.0.1.0 ... linking ... done.
&gt; Loading package process-1.0.1.2 ... linking ... done.
&gt; Loading package hslogger-1.0.7 ... linking ... done.
&gt; Loading package deepseq-1.1.0.0 ... linking ... done.
&gt; Loading package parallel-2.2.0.1 ... linking ... done.
&gt; Loading package strict-concurrency-0.2.2 ... linking ... done.
&gt; Loading package unix-compat-0.1.2.1 ... linking ... done.
&gt; Loading package happstack-util-0.4.1 ... linking ... done.
&gt; Loading package binary-0.5.0.2 ... linking ... done.
&gt; Loading package haskell98 ... linking ... done.
&gt; Loading package HaXml-1.13.3 ... linking ... done.
&gt; Loading package ffi-1.0 ... linking ... done.
&gt; ghc:
&gt; unknown symbol
&gt; `_sybzmwithzmclasszm0zi6zi1_DataziGenericsziSYBziWithClassziInstances_dataT ypeZMad6eZN_closure'
&gt; &lt;&lt;&lt;&lt;&lt;
</pre><p>
or in some private code:
</p>
<pre class="wiki">Loading package extensible-exceptions-0.1.1.1 ... linking ... done.
ghc: /usr/lib/haskell-packages/ghc6/lib/generic-formlets-1.53/ghc-6.12.1/HSgeneric-formlets-1.53.o: unknown symbol `sybzmwithzmclasszm0zi6zi1_DataziGenericsziSYBziWithClassziInstances_constrZMad9AZN_closure'
Loading package hsemail-1.3 ... linking ... done.
</pre><p>
The work around so far has been to compile with <tt>-O0</tt>. However, it is not consistent *what* needs to be compiled with -O0. In the case of happstack-data, compiling happstack-data with <tt>-O0</tt> fixed the problem. In the second example I pasted, I actually had to recompile the library that the missing symbol was coming from with <tt>-O0</tt>.
</p>
<p>
I have also seen similar linking errors during the final link of an executable:
</p>
<pre class="wiki">Linking dist/build/senioritymatters/senioritymatters ...
dist/build/senioritymatters/senioritymatters-tmp/Senior/Server.o: In function `s5OwR_info':
(.text+0x10559): undefined reference to `sybzmwithzmclasszm0zi6zi1_DataziGenericsziSYBziWithClassziInstances_constrZMad6fZN_closure'
dist/build/senioritymatters/senioritymatters-tmp/Senior/Server.o: In function `r5Hbl_info':
(.text+0x105a1): undefined reference to `sybzmwithzmclasszm0zi6zi1_DataziGenericsziSYBziWithClassziInstances_dataTypeZMad6eZN_closure'
dist/build/senioritymatters/senioritymatters-tmp/Senior/Server.o: In function `r5Hbj_srt':
(.data+0x2cec): undefined reference to `sybzmwithzmclasszm0zi6zi1_DataziGenericsziSYBziWithClassziInstances_constrZMad6fZN_closure'
dist/build/senioritymatters/senioritymatters-tmp/Senior/Server.o: In function `r5Hbl_srt':
(.data+0x2cf8): undefined reference to `sybzmwithzmclasszm0zi6zi1_DataziGenericsziSYBziWithClassziInstances_dataTypeZMad6eZN_closure'
dist/build/senioritymatters/senioritymatters-tmp/Senior/Store.o: In function `s5uFy_info':
(.text+0x7ad5): undefined reference to `sybzmwithzmclasszm0zi6zi1_DataziGenericsziSYBziWithClassziInstances_constrZMad6fZN_closure'
dist/build/senioritymatters/senioritymatters-tmp/Senior/Store.o: In function `s5uFy_info':
(.text+0x7b1d): undefined reference to `sybzmwithzmclasszm0zi6zi1_DataziGenericsziSYBziWithClassziInstances_dataTypeZMad6eZN_closure'
dist/build/senioritymatters/senioritymatters-tmp/Senior/Store.o: In function `r5rnO_closure':
(.data+0x16b0): undefined reference to `sybzmwithzmclasszm0zi6zi1_DataziGenericsziSYBziWithClassziInstances_constrZMad6fZN_closure'
dist/build/senioritymatters/senioritymatters-tmp/Senior/Store.o: In function `r5rnO_closure':
(.data+0x16bc): undefined reference to `sybzmwithzmclasszm0zi6zi1_DataziGenericsziSYBziWithClassziInstances_dataTypeZMad6eZN_closure'
dist/build/senioritymatters/senioritymatters-tmp/Senior/Types/Instances.o: In function `s48Uv_info':
(.text+0x6151d): undefined reference to `sybzmwithzmclasszm0zi6zi1_DataziGenericsziSYBziWithClassziInstances_constrZMad6fZN_closure'
dist/build/senioritymatters/senioritymatters-tmp/Senior/Types/Instances.o: In function `s48Uv_info':
(.text+0x61565): undefined reference to `sybzmwithzmclasszm0zi6zi1_DataziGenericsziSYBziWithClassziInstances_dataTypeZMad6eZN_closure'
dist/build/senioritymatters/senioritymatters-tmp/Senior/Types/Instances.o: In function `s4962_info':
(.text+0x61d69): undefined reference to `sybzmwithzmclasszm0zi6zi1_DataziGenericsziSYBziWithClassziInstances_constrZMad6fZN_closure'
dist/build/senioritymatters/senioritymatters-tmp/Senior/Types/Instances.o: In function `s4962_info':
(.text+0x61db1): undefined reference to `sybzmwithzmclasszm0zi6zi1_DataziGenericsziSYBziWithClassziInstances_dataTypeZMad6eZN_closure'
dist/build/senioritymatters/senioritymatters-tmp/Senior/Types/Instances.o: In function `s4jTk_info':
(.text+0x860c1): undefined reference to `sybzmwithzmclasszm0zi6zi1_DataziGenericsziSYBziWithClassziInstances_constrZMad6fZN_closure'
dist/build/senioritymatters/senioritymatters-tmp/Senior/Types/Instances.o: In function `s4jTk_info':
(.text+0x86109): undefined reference to `sybzmwithzmclasszm0zi6zi1_DataziGenericsziSYBziWithClassziInstances_dataTypeZMad6eZN_closure'
dist/build/senioritymatters/senioritymatters-tmp/Senior/Types/Instances.o: In function `s3xkI_closure':
(.data+0x74c8): undefined reference to `sybzmwithzmclasszm0zi6zi1_DataziGenericsziSYBziWithClassziInstances_constrZMad6fZN_closure'
dist/build/senioritymatters/senioritymatters-tmp/Senior/Types/Instances.o: In function `s3xkI_closure':
(.data+0x74d4): undefined reference to `sybzmwithzmclasszm0zi6zi1_DataziGenericsziSYBziWithClassziInstances_dataTypeZMad6eZN_closure'
dist/build/senioritymatters/senioritymatters-tmp/Senior/Types/Instances.o: In function `s3xkI_closure':
(.data+0x76a8): undefined reference to `sybzmwithzmclasszm0zi6zi1_DataziGenericsziSYBziWithClassziInstances_constrZMad6fZN_closure'
dist/build/senioritymatters/senioritymatters-tmp/Senior/Types/Instances.o: In function `s3xkI_closure':
(.data+0x76b4): undefined reference to `sybzmwithzmclasszm0zi6zi1_DataziGenericsziSYBziWithClassziInstances_dataTypeZMad6eZN_closure'
dist/build/senioritymatters/senioritymatters-tmp/Senior/Types/Instances.o: In function `r3or3_closure':
(.data+0xb824): undefined reference to `sybzmwithzmclasszm0zi6zi1_DataziGenericsziSYBziWithClassziInstances_constrZMad6fZN_closure'
dist/build/senioritymatters/senioritymatters-tmp/Senior/Types/Instances.o: In function `r3or3_closure':
(.data+0xb830): undefined reference to `sybzmwithzmclasszm0zi6zi1_DataziGenericsziSYBziWithClassziInstances_dataTypeZMad6eZN_closure'
collect2: ld returned 1 exit status
done.
Loading package QuickCheck-2.1.0.2 ... linking ... done.
Loading package ffi-1.0 ... linking ... done.
</pre><p>
In this case, compiling with <tt>-O0</tt> also fixed the linking errors. However, I was also able to compile with <tt>-O2 -fignore-interface-pragmas</tt>. In the case of the template-haskell errors, <tt>-fignore-interface-pragmas</tt> did not help.
</p>
<p>
It seems that some GHC 6.12.1 users are able to compile happstack-data with out any problems. We have seen it happen under Linux and Mac OS X, and 32bit and 64bit. So there is no clear pattern there yet.
</p>
<p>
The one pattern I have noticed is that the undefined symbols/references always seem to end with <tt>_closure</tt>.
</p>
Resultshttp://ghc.haskell.org/trac/ghc/ticket/3799#changeloghttp://ghc.haskell.org/trac/ghc/ticket/3803
http://ghc.haskell.org/trac/ghc/ticket/3803#3803: addCoverageTicksTobind should not panic when file location is NothingSun, 03 Jan 2010 19:47:00 GMTclemens<p>
compiler/deSugar/Coverage.lhs:
</p>
<pre class="wiki">addCoverageTicksToBinds dflags mod mod_loc tyCons binds = do
let orig_file =
case ml_hs_file mod_loc of
Just file -&gt; file
Nothing -&gt; panic "can not find the original file during hpc trans"
</pre><p>
Is there any reason for this function to panic? It is the only function (at least in my use-case) of the GHC API that panics on ms_hs_file = Nothing. I suggest to handle this more graceful and return emptyHpcInfo and emptyModBreaks just as in the case of file ending in .boot
</p>
Resultshttp://ghc.haskell.org/trac/ghc/ticket/3803#changeloghttp://ghc.haskell.org/trac/ghc/ticket/3804
http://ghc.haskell.org/trac/ghc/ticket/3804#3804: strange output of mkGHCConstants on SunOS 5.8/sparcMon, 04 Jan 2010 12:02:45 GMTCBa<p>
mkGHCConstants generates a file with:
</p>
<pre class="wiki">oFFSET_StgRegTable_rR1 :: Int
oFFSET_StgRegTable_rR1 = zd
oFFSET_StgRegTable_rR2 :: Int
oFFSET_StgRegTable_rR2 = zd
...
</pre><p>
whatever zd is. My bootstrap-ghc is 6.8.3.
</p>
Resultshttp://ghc.haskell.org/trac/ghc/ticket/3804#changeloghttp://ghc.haskell.org/trac/ghc/ticket/3809
http://ghc.haskell.org/trac/ghc/ticket/3809#3809: template-haskell 2.4 fails to compile with base 4.1Thu, 07 Jan 2010 14:48:47 GMTbenmachine<p>
The problem is CharConstr, which doesn't exist in Data.Data prior to base 4.2. I suppose the easiest fix is to update the build-depends in the cabal file.
</p>
<p>
But for what it's worth I had a look and the mention of CharConstr is so brief that I wonder if it's not worth factoring it out somehow in a way that maintains compatibility – commenting out that single two-line case branch allows the build to complete fine.
</p>
Resultshttp://ghc.haskell.org/trac/ghc/ticket/3809#changeloghttp://ghc.haskell.org/trac/ghc/ticket/3813
http://ghc.haskell.org/trac/ghc/ticket/3813#3813: Invalid warning from GHCiSat, 09 Jan 2010 23:33:12 GMTNeilMitchell<pre class="wiki">C:\Neil&gt;ghci -Wall
GHCi, version 6.10.3.20090530: http://www.haskell.org/ghc/ :? for help
Loading package ghc-prim ... linking ... done.
Loading package integer ... linking ... done.
Loading package base ... linking ... done.
Prelude&gt; x &lt;- return True
&lt;interactive&gt;:1:0: Warning: Defined but not used: `x'
Prelude&gt; x
True
Prelude&gt;
</pre><p>
This error comes up in practice when writing .ghci files, for example for HLint. The user who reported it to me was running GHC 6.12.1.
</p>
Resultshttp://ghc.haskell.org/trac/ghc/ticket/3813#changeloghttp://ghc.haskell.org/trac/ghc/ticket/3815
http://ghc.haskell.org/trac/ghc/ticket/3815#3815: System.Win32.Types.failWith segfaults on unknown error codeMon, 11 Jan 2010 03:57:00 GMTdherington<p>
If a (Windows) system call returns an error code not known to FormatMessage, System.Win32.Types.failWith segfaults. failWith incorrectly assumes that getErrorMessage never returns a NULL pointer.
</p>
<p>
A simple fix in failWith is to replace:
</p>
<pre class="wiki"> msg &lt;- peekTString c_msg
-- We ignore failure of freeing c_msg, given we're already failing
_ &lt;- localFree c_msg
</pre><p>
by:
</p>
<pre class="wiki"> msg &lt;- if c_msg == nullPtr
then return $ "Error 0x" ++ Numeric.showHex err_code ""
else do msg &lt;- peekTString c_msg
-- We ignore failure of freeing c_msg, given we're already failing
_ &lt;- localFree c_msg
return msg
</pre>Resultshttp://ghc.haskell.org/trac/ghc/ticket/3815#changeloghttp://ghc.haskell.org/trac/ghc/ticket/3816
http://ghc.haskell.org/trac/ghc/ticket/3816#3816: System.Posix.GetAllGroupEntries returns 0 groups for 2nd and subsequent callsMon, 11 Jan 2010 22:07:55 GMTtphyahoo<p>
This is on 6.10.4, could someone check whether still a bug on 6.12?
</p>
<pre class="wiki"> #haskell Jan 11 2010:
&lt;patch-tag&gt; liftM length System.Posix.getAllGroupEntries
&lt;patch-tag&gt; 1819
&lt;patch-tag&gt; Prelude System.Posix Control.Monad&gt; liftM length
&lt;patch-tag&gt; 0
</pre><blockquote>
<p>
lispy/cale confirmed behavior, and cale suggested fix:
</p>
</blockquote>
<pre class="wiki"> &lt;lispy&gt; patch-tag: http://www.haskell.org/ghc/docs/6.10.4/html/libraries/unix/src/System-Posix-User.html#getAllGroupEntries
&lt;Cale&gt; getAllUserEntries =
&lt;Cale&gt; withMVar lock $ \_ -&gt; bracket_ c_setpwent c_endpwent $ worker []
&lt;Cale&gt; getAllUserEntries is properly bracketed
&lt;Cale&gt; getAllGroupEntries = withMVar lock $ \_ -&gt; worker []
&lt;lispy&gt; http://linux.about.com/library/cmd/blcmdl3_getgrent.htm
</pre><p>
function has changed from 6.10.4 to 6.12 but I'm not sure if this fixed the bug:
</p>
<ul><li>6.10.4: <a href="http://www.haskell.org/ghc/docs/6.10.4/html/libraries/unix/src/System-Posix-User.html#getAllGroupEntries">http://www.haskell.org/ghc/docs/6.10.4/html/libraries/unix/src/System-Posix-User.html#getAllGroupEntries</a>
</li><li>6.12: <a class="ext-link" href="http://hackage.haskell.org/packages/archive/unix/2.4.0.0/doc/html/src/System-Posix-User.html"><span class="icon">​</span>http://hackage.haskell.org/packages/archive/unix/2.4.0.0/doc/html/src/System-Posix-User.html</a>
</li></ul>Resultshttp://ghc.haskell.org/trac/ghc/ticket/3816#changeloghttp://ghc.haskell.org/trac/ghc/ticket/3821
http://ghc.haskell.org/trac/ghc/ticket/3821#3821: Trace.Hpc.Reflect.examineTix segfaults on 64bitFri, 15 Jan 2010 10:31:41 GMTTristanAllwood<p>
The following seg-faults on my 64bit ghc 6.12.1 when compiled with <tt>-fhpc</tt>
</p>
<pre class="wiki">module Main where
import B
import Trace.Hpc.Reflect
main :: IO ()
main = do
examineTix
print (foo 3)
return ()
</pre><pre class="wiki">module B where
foo 0 = 0
foo n = 1 + foo (n-1)
</pre><pre class="wiki">&gt;ghc --make -fforce-recomp -fhpc Main
[1 of 2] Compiling B ( B.hs, B.o )
[2 of 2] Compiling Main ( Main.hs, Main.o )
Linking Main ...
10:21:55 - tora@colorado:/tmp/HPC
&gt;./Main
Segmentation fault
</pre><p>
I believe the cause is that
<tt> data ModuleInfo = ModuleInfo String Int Hash (Ptr Word64) </tt>
in <tt>Trace.Hpc.Reflect</tt> uses a variable sized <tt>Int</tt> instead of a fixed (32bit if I'm reading the sources correctly) Word32 for the count.
</p>
<p>
I've attached a patch that should fix the issue.
</p>
Resultshttp://ghc.haskell.org/trac/ghc/ticket/3821#changeloghttp://ghc.haskell.org/trac/ghc/ticket/3823
http://ghc.haskell.org/trac/ghc/ticket/3823#3823: GHC 6.12 breaks combination of records and mutually recursive modulesFri, 15 Jan 2010 23:00:43 GMTmboes<p>
Take the following code for two mutually recursive modules A and B:
</p>
<pre class="wiki">module A where
import B
data A = X { x :: Bool } | Y
y :: A -&gt; A
y = \_ -&gt; Y
-- A.hs-boot
module A where
data A = X { x :: Bool } | Y
y :: A -&gt; A
module B where
import {-# SOURCE #-} A
data B = A A
a = x (X True)
b = y a
</pre><p>
Compiling this code with ghc --make or ghci gives:
</p>
<pre class="wiki">[1 of 3] Compiling A[boot] ( A.hs-boot, A.o-boot )
[2 of 3] Compiling B ( B.hs, B.o )
B.hs:7:4:
Can't find interface-file declaration for variable x
Probable cause: bug in .hi-boot file, or inconsistent .hi file
Use -ddump-if-trace to get an idea of which file caused the error
In the expression: x (X True)
In the definition of `a': a = x (X True)
</pre><p>
This code used to work in GHC 6.10.
</p>
<p>
Note that this issue breaks the build of the hmk package on Hackage. Doubtless other packages making use of mutually recursive modules hit this snag too.
</p>
Resultshttp://ghc.haskell.org/trac/ghc/ticket/3823#changeloghttp://ghc.haskell.org/trac/ghc/ticket/3832
http://ghc.haskell.org/trac/ghc/ticket/3832#3832: openTempFile does not apply an encoding to the streamWed, 20 Jan 2010 14:14:35 GMTross<p>
In the following program, the output is written as a raw byte, even in a UTF locale:
</p>
<pre class="wiki">module Main where
import System.IO
main = do
(_, h) &lt;- openTempFile "." "test.txt"
hPutStrLn h $ "\xa9" -- Copyright symbol
hClose h
</pre>Resultshttp://ghc.haskell.org/trac/ghc/ticket/3832#changeloghttp://ghc.haskell.org/trac/ghc/ticket/3835
http://ghc.haskell.org/trac/ghc/ticket/3835#3835: unpleasant linker warningFri, 22 Jan 2010 16:17:53 GMTmaeder<p>
When linking any binary (i.e. cabal) that uses the network package I get the following warning:
</p>
<pre class="wiki">ld: warning: symbol `store' has differing types:
(file /usr/lib/libnsl.so type=FUNC; file /home/pub-bkb/pc-solaris/ghc/ghc-6.12.1/lib/ghc-6.12.1/libHSrts_thr.a(Globals.thr_o) type=OBJT);
/home/pub-bkb/pc-solaris/ghc/ghc-6.12.1/lib/ghc-6.12.1/libHSrts_thr.a(Globals.thr_o) definition taken
ld: warning: symbol `store' has differing types:
(file /usr/lib/libnsl.so type=FUNC; file /home/pub-bkb/pc-solaris/ghc/ghc-6.12.1/lib/ghc-6.12.1/libHSrts_thr.a(Globals.thr_o) type=OBJT);
</pre><p>
I've got network-2.2.1.7 that as extra-libraries: nsl socket
</p>
Resultshttp://ghc.haskell.org/trac/ghc/ticket/3835#changeloghttp://ghc.haskell.org/trac/ghc/ticket/3847
http://ghc.haskell.org/trac/ghc/ticket/3847#3847: Windows installer has incorrect documentation shortcutFri, 29 Jan 2010 15:20:29 GMTNeilMitchell<p>
With the Windows install of 6.12.1, the link on the start menu at GHC/6.12.1/Documentation points at <a class="ext-link" href="file:///C:/ghc/ghc-6.12.1/doc/index.html"><span class="icon">​</span>file:///C:/ghc/ghc-6.12.1/doc/index.html</a>, when the documentation is really located at <a class="ext-link" href="file:///C:/ghc/ghc-6.12.1/doc/html/index.html"><span class="icon">​</span>file:///C:/ghc/ghc-6.12.1/doc/html/index.html</a>. All the other documentation links are similarly incorrect.
</p>
Resultshttp://ghc.haskell.org/trac/ghc/ticket/3847#changeloghttp://ghc.haskell.org/trac/ghc/ticket/3848
http://ghc.haskell.org/trac/ghc/ticket/3848#3848: Error message typo in rts/RtsAPI.cSat, 30 Jan 2010 02:29:32 GMTlarsv<p>
In rts/RtsAPI.c in the error message about re-entrant finalizers for ForeignPtrs, there is a misspelling of Haskell as Haskll.
</p>
Resultshttp://ghc.haskell.org/trac/ghc/ticket/3848#changeloghttp://ghc.haskell.org/trac/ghc/ticket/3849
http://ghc.haskell.org/trac/ghc/ticket/3849#3849: 6.12.1: make framework-pkg on OS X creates package with broken installerSat, 30 Jan 2010 20:50:55 GMTkorpios<p>
System: OS X 10.6 (Snow Leopard), Intel Core 2 Duo system (64-bit capable, running 32-bit kernel), universal (64/32 combined) MacPorts
</p>
<p>
Observed: <tt>.pkg</tt> file built via <tt>make framework-pkg</tt> starts Installer, but does not show a dialog box so installation can proceed.
</p>
<p>
Expected: Opening the <tt>.pkg</tt> file should have shown a dialog box, same as the <tt>.pkg</tt> available from the GHC download page.
</p>
<p>
I installed GHC 6.12.1 on OS X via the binary <tt>.pkg</tt>, and then proceeded to rebuild it from source via <tt>make framework-pkg</tt> so it would use my MacPorts libraries and not break on libiconv (so I could then install xmonad-contrib successfully). The build process completes and creates a file <tt>GHC-6.12.1-i386.pkg</tt>. When opening this file, Installer launches, but nothing else happens — no dialog opens, etc. Interestingly, though, the contents seem fine; this pkg file can be extracted manually via <tt>xar</tt>, and then the package contents therein extracted via <tt>gzip</tt> and <tt>cpio</tt>, and the extracted framework directory can then take the place of the existing <tt>/Library/Frameworks/GHC.framework</tt> directory and everything works as expected (including not breaking on libiconv).
</p>
Resultshttp://ghc.haskell.org/trac/ghc/ticket/3849#changeloghttp://ghc.haskell.org/trac/ghc/ticket/3854
http://ghc.haskell.org/trac/ghc/ticket/3854#3854: trac priority and milestone are completely hidden when not logged inTue, 02 Feb 2010 19:03:09 GMTigloo<p>
trac priority and milestone are completely hidden when not logged in.
</p>
<p>
Only editing should be disabled.
</p>
Resultshttp://ghc.haskell.org/trac/ghc/ticket/3854#changeloghttp://ghc.haskell.org/trac/ghc/ticket/3860
http://ghc.haskell.org/trac/ghc/ticket/3860#3860: bindists should check you have a new enough makeWed, 03 Feb 2010 19:28:28 GMTigloo<p>
The <tt>configure.ac</tt> check for <tt>make</tt> being too old should be put in the distrib <tt>configure.ac.in</tt> too.
</p>
Resultshttp://ghc.haskell.org/trac/ghc/ticket/3860#changeloghttp://ghc.haskell.org/trac/ghc/ticket/3864
http://ghc.haskell.org/trac/ghc/ticket/3864#3864: Bad error message if $TMP does not existFri, 05 Feb 2010 16:13:29 GMTNeilMitchell<pre class="wiki">$ ghc --version
The Glorious Glasgow Haskell Compilation System, version 6.10.4
$ set TMP=c:\none
$ ghc --make Main.hs
CreateDirectory: does not exist (The system cannot find the path specified.)
</pre><p>
If the <tt>%TMP%</tt> environment variable is set to a directory that does not exist, then GHC gives a very uninformative error message. I suggest that <tt>CreateDirectory</tt> always give the name of the directory when it fails, and that GHC traps this error and gives a better error.
</p>
<p>
Tracking this bug down took a while - I'd like to spare other users my pain :-)
</p>
Resultshttp://ghc.haskell.org/trac/ghc/ticket/3864#changeloghttp://ghc.haskell.org/trac/ghc/ticket/3866
http://ghc.haskell.org/trac/ghc/ticket/3866#3866: Constr Eq instance should have better documentation or semanticsSun, 07 Feb 2010 19:10:05 GMTbatterseapower<p>
The following code doesn't do what you expect:
</p>
<pre class="wiki">data WithData = forall a. Data a =&gt; WithData a
tupleDataCast :: Data a =&gt; ([WithData] -&gt; c) -&gt; a -&gt; Maybe c
tupleDataCast f x | Just (s, _) &lt;- find ((toConstr x ==) . snd) tuples
= trace (show (toConstr x, s)) $ Just (f [gmapQi i WithData x | i &lt;- [0..s - 1]])
| otherwise = Nothing
where tuples = [2..] `zip` [toConstr ((), ()), toConstr ((), (), ()), toConstr ((), (), (), ()), toConstr ((), (), (), (), ()), toConstr ((), (), (), (), (), ())]
</pre><p>
The reason is that, for example:
</p>
<pre class="wiki">Prelude Data.Data&gt; toConstr False == toConstr ()
True
Prelude Data.Data&gt; toConstr True == toConstr ()
False
</pre><p>
The Constr data type is only compared on the index. The DataType information in the Constr is totally ignored. This is very surprising behaviour!
</p>
<p>
According to a mailing list thread (<a class="ext-link" href="http://www.mail-archive.com/glasgow-haskell-bugs@haskell.org/msg08207.html"><span class="icon">​</span>http://www.mail-archive.com/glasgow-haskell-bugs@haskell.org/msg08207.html</a>) this is done for efficiency reasons.
</p>
<p>
Either the documentation should mention this behaviour, or the Eq instance should be fixed. My preference is for the latter -- though existing expectations of Constr == efficiency and semantics may be too entrenched to change the behaviour now.
</p>
Resultshttp://ghc.haskell.org/trac/ghc/ticket/3866#changeloghttp://ghc.haskell.org/trac/ghc/ticket/3874
http://ghc.haskell.org/trac/ghc/ticket/3874#3874: GHC.Exts.traceEvent segfaultsThu, 11 Feb 2010 04:03:07 GMTcjs<p>
When I call the GC.Exts.traceEvent function (argument: "hello") with event logging enabled (i.e., compiled with -eventlog and run with -ls) my program generates a segmentation fault. Here is the gdb backtrace:
</p>
<pre class="wiki">#0 0x00007f3ad6744a2f in vfprintf () from /lib/libc.so.6
#1 0x00007f3ad677039a in vsnprintf () from /lib/libc.so.6
#2 0x00000000004476c4 in postLogMsg (eb=0x8160d0, type=19,
msg=0x7f3ad5d7e010 "hello", ap=0x0) at rts/eventlog/EventLog.c:403
#3 0x0000000000447853 in postUserMsg (cap=0x69b780,
msg=0x7f3ad5d7e010 "hello") at rts/eventlog/EventLog.c:433
#4 0x000000000043b012 in traceUserMsg (cap=0x69b780,
msg=0x7f3ad5d7e010 "hello") at rts/Trace.c:290
#5 0x000000000044e237 in stg_traceEventzh ()
#6 0x0000000000000000 in ?? ()
</pre><p>
It's not at all clear to me what could be going wrong here.
</p>
Resultshttp://ghc.haskell.org/trac/ghc/ticket/3874#changeloghttp://ghc.haskell.org/trac/ghc/ticket/3875
http://ghc.haskell.org/trac/ghc/ticket/3875#3875: DPH QuickHull example crashes on SPARC with -N > 1Thu, 11 Feb 2010 08:54:47 GMTbenl<pre class="wiki">... ghc-head-build/libraries/dph/examples/quickhull$ par/quickhull 10000 +RTS -N1
N = 10000: 503/520 503/520 503/520
... ghc-head-build/libraries/dph/examples/quickhull$ par/quickhull 10000 +RTS -N2
Bus Error (core dumped)
</pre><p>
GDB says:
</p>
<pre class="wiki">(gdb) bt
#0 0x0197f5ec in eval_thunk_selector ()
#1 0x019806e0 in scavenge_block ()
#2 0x01981b48 in scavenge_loop ()
#3 0x01974934 in scavenge_until_all_done ()
#4 0x01975828 in GarbageCollect ()
#5 0x0196cd3c in scheduleDoGC ()
#6 0x0196e708 in schedule ()
#7 0x0196ba54 in real_main ()
#8 0x0196bbfc in hs_main ()
#9 0x000121bc in _start ()
</pre>Resultshttp://ghc.haskell.org/trac/ghc/ticket/3875#changeloghttp://ghc.haskell.org/trac/ghc/ticket/3878
http://ghc.haskell.org/trac/ghc/ticket/3878#3878: doesFileExist doesn't work for some /dev files in ghc 6.12Fri, 12 Feb 2010 11:10:51 GMTmarcotmarcot<p>
Hi. I've noticed this with a program that checks for a lvm image. Here's the situation:
</p>
<pre class="wiki">Prelude System.Directory&gt; doesFileExist "/dev/null"
True
Prelude System.Directory&gt; doesFileExist "/dev/stdin"
True
Prelude System.Directory&gt; doesFileExist "/dev/sda0"
False
Prelude System.Directory&gt; doesFileExist "/dev/zezinho/sid"
False
</pre><p>
All of these files exist in my system:
</p>
<pre class="wiki">marcot@zezinho:/dev$ ls -l null sda1 stdin zezinho/sid /proc/self/fd/0 mapper/zezinho-sid /dev/pts/5
crw--w---- 1 marcot tty 136, 5 Fev 12 09:09 /dev/pts/5
brw-rw---- 1 root disk 254, 4 Fev 12 08:55 mapper/zezinho-sid
crw-rw-rw- 1 root root 1, 3 Fev 12 08:33 null
lrwx------ 1 marcot marcot 64 Fev 12 09:09 /proc/self/fd/0 -&gt; /dev/pts/5
brw-rw---- 1 root disk 8, 1 Fev 12 08:55 sda1
lrwxrwxrwx 1 root root 15 Fev 12 08:33 stdin -&gt; /proc/self/fd/0
lrwxrwxrwx 1 root root 21 Fev 12 08:55 zezinho/sid -&gt; ../mapper/zezinho-sid
</pre>Resultshttp://ghc.haskell.org/trac/ghc/ticket/3878#changeloghttp://ghc.haskell.org/trac/ghc/ticket/3893
http://ghc.haskell.org/trac/ghc/ticket/3893#3893: GHC on Windows lacks C++ supportMon, 22 Feb 2010 10:48:27 GMTNeilMitchell<p>
In GHC 6.10 support was added to the Windows distribution for building C++. In GHC 6.12 a key library to make this support work was removed, probably be accident.
</p>
<p>
The missing file is {{C:\ghc\ghc-6.12.1\mingw\lib\libstdc++.a}}, which I have solved by copying the file from {{C:\ghc\ghc-6.10.4\gcc-lib}}. It would be best if the correct file was copied from the right Mingw release.
</p>
Resultshttp://ghc.haskell.org/trac/ghc/ticket/3893#changeloghttp://ghc.haskell.org/trac/ghc/ticket/3900
http://ghc.haskell.org/trac/ghc/ticket/3900#3900: CAFs used after GC with shared libsFri, 26 Feb 2010 10:38:10 GMTaugustss<p>
When using dlopen() it's possible that the loaded library introduces references to CAFs that have already been garbage collected. Chaos follows.
</p>
Resultshttp://ghc.haskell.org/trac/ghc/ticket/3900#changeloghttp://ghc.haskell.org/trac/ghc/ticket/3904
http://ghc.haskell.org/trac/ghc/ticket/3904#3904: Bug in shipped gcc makes profiling lose resolutionMon, 01 Mar 2010 14:53:42 GMTaugustss<p>
When profiling on Windows the BEGIN_SAMPLE/END_SAMPLE do not contain a fractional part in the time information. As far as I can tell its a bug in gcc. I've included some C code that shows the problem.
</p>
Resultshttp://ghc.haskell.org/trac/ghc/ticket/3904#changeloghttp://ghc.haskell.org/trac/ghc/ticket/3914
http://ghc.haskell.org/trac/ghc/ticket/3914#3914: handleToFd closes Fd when Handle is GC'dMon, 08 Mar 2010 00:05:33 GMTdanderson<p>
The following reproduction case creates a TCP server that will read forever from the first client that connects to it. Having a client do so (eg. with <tt>cat /dev/urandom | nc localhost 4242</tt>) will fairly rapidly cause the server to crash with a "Bad file descriptor" exception.
</p>
<pre class="wiki">module Main where
import Control.Monad(forever)
import Network
import System.IO
import System.Posix.IO(fdToHandle, handleToFd)
main = withSocketsDo $ do
(hdl, _, _) &lt;- listenOn (PortNumber 4242) &gt;&gt;= accept
newHdl &lt;- handleToFd hdl &gt;&gt;= fdToHandle
forever $ hGetChar newHdl &gt;&gt;= putChar &gt;&gt; hFlush stdout
</pre><p>
My hunch on the cause is that handleToFd doesn't let go of the underlying system file descriptor when it returns the Fd. Later, when the GC runs, it collects hdl and incorrectly closes the system fd, now in use by newHdl.
</p>
<p>
An strace of the server binary confirms this sequence of events (shortened to the essentials, but the sequencing is as shown - 4 is the hdl/newHdl file descriptor):
</p>
<pre class="wiki">...
select(5, [4], [], NULL, {134, 217727}) = 1 (in [4], left {134, 203169})
...
close(4) = 0
...
select(5, [4], [], NULL, {0, 0}) = -1 EBADF (Bad file descriptor)
write(2, "Minimal: ", 9Minimal: ) = 9
write(2, "&lt;file descriptor: 4&gt;: hGetChar: "..., 70&lt;file descriptor: 4&gt;: hGetChar: invalid argument (Bad file descriptor)) = 70
</pre><p>
Running the binary with '+RTS -s' also shows that some GC passes did occur during the short lifetime of the program, further pointing the finger at incorrect collection of the system fd.
</p>
<p>
While the reproduction recipe seems silly, the handleToFd &gt;&gt;= fdToHandle scenario is actually very useful when doing low level FFI. The real code where I hit this bug is <a class="ext-link" href="http://bitbucket.org/danderson/tunskell/src/330b5edba1dc/Ioctl.hsc"><span class="icon">​</span>http://bitbucket.org/danderson/tunskell/src/330b5edba1dc/Ioctl.hsc</a> . I extract the Fd in order to make an ioctl() call, then return a new Handle of that Fd after the ioctl() finishes. Using this pattern, the code reading from that tweaked Handle dies after the first GC pass.
</p>
Resultshttp://ghc.haskell.org/trac/ghc/ticket/3914#changeloghttp://ghc.haskell.org/trac/ghc/ticket/3929
http://ghc.haskell.org/trac/ghc/ticket/3929#3929: hsc2hs can't find gcc when run directly on WindowsFri, 19 Mar 2010 15:58:27 GMTigloo<p>
hsc2hs can't find gcc when run directly on Windows (but works fine when run by Cabal).
</p>
<p>
It probably needs a wrapper executable.
</p>
<pre class="wiki">=====&gt; hsc2hs001(normal) 1 of 2 [0, 0, 0]
cd . &amp;&amp; $MAKE -s --no-print-directory hsc2hs001 &lt;/dev/null &gt;hsc2hs001.run.stdout 2&gt;hsc2hs001.run.stderr
Wrong exit code (expected 0 , actual 2 )
Stdout:
Stderr:
Can't find gcc
make[1]: *** [hsc2hs001] Error 1
</pre>Resultshttp://ghc.haskell.org/trac/ghc/ticket/3929#changeloghttp://ghc.haskell.org/trac/ghc/ticket/3934
http://ghc.haskell.org/trac/ghc/ticket/3934#3934: add licence to Windows installerMon, 22 Mar 2010 19:42:26 GMTigloo<p>
Add the licence(s) to the Windows installer. We can probably copy the text generation from the OS X installer.
</p>
Resultshttp://ghc.haskell.org/trac/ghc/ticket/3934#changeloghttp://ghc.haskell.org/trac/ghc/ticket/3956
http://ghc.haskell.org/trac/ghc/ticket/3956#3956: GHC6.12.2-RC1 runtime error: Invalid object in isRetainer(): 32Sat, 03 Apr 2010 18:35:20 GMTjlouis<p>
Against GHC6.12.2-RC1:
</p>
<p>
Running Combinatorrent, version g2a3dff0 with retainer profiling +RTS -hr -RTS produces the following bug:
</p>
<pre class="wiki">This is Combinatorrent ☠ version v0.1.1-180-g5334c4f
For help type 'help'
Process.TorrentManager: Process exiting due to ex: foo.torrent: openBinaryFile: does not exist (No such file or directory)
PeerPool: Process exiting due to ex: thread blocked indefinitely in an MVar operation
Combinatorrent: internal error: Invalid object in isRetainer(): 32
(GHC version 6.12.1.20100330 for x86_64_unknown_linux)
Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug
Aborted
</pre><p>
I can't select the 6.12.2-RC1 as the version with this problem in the drop-down list. The version of combinatorrent with v0.1.1-180-g5334c4f, publicly available at
</p>
<p>
<a class="ext-link" href="http://github.com/jlouis/combinatorrent/commit/5334c4f767970b2bd697ab9e86bdf66258b54de7"><span class="icon">​</span>http://github.com/jlouis/combinatorrent/commit/5334c4f767970b2bd697ab9e86bdf66258b54de7</a>
</p>
<p>
can reproduce the problem: Run ./Combinatorrent +RTS -hr -RTS foo.torrent (which doesn't have to exist) to get the above error message.
</p>
<p>
This is also a regression: Last known version that works with retainer profiling: GHC 6.12.1, if you want to bisect the problem.
</p>
Resultshttp://ghc.haskell.org/trac/ghc/ticket/3956#changelog