ASSERT failed! file typecheck/TcMType.lhs line 442 t_a7Fa{tv} [tau]
As discussed this afternoon on #ghc.
From the attached tarball, unpack, cd sessions2, ghci Control/Concurrent/Session/Queens.hs, main
What should happen is that it prints "False". However, for me it consistently segfaults. GDB reveals things like:
*Control.Concurrent.Session.Queens> main
Loading package mtl-1.1.0.0 ... linking ... done.
Loading package array-0.1.0.0 ... linking ... done.
Loading package containers-0.1.0.1 ... linking ... done.
Program received signal SIGSEGV, Segmentation fault.
[Switching to Thread 0x41001950 (LWP 26393)]
0x00002b76022eae6b in memcpy () from /lib/libc.so.6
(gdb) bt
#0 0x00002b76022eae6b in memcpy () from /lib/libc.so.6
#1 0x000000000167f7b9 in schedule (initialCapability=<value optimized out>, task=0x1b9d100) at Schedule.c:2847
#2 0x000000000167f94f in workerStart (task=0x1b9d100) at Schedule.c:2528
#3 0x00002b760205e017 in start_thread () from /lib/libpthread.so.0
#4 0x00002b76023385bd in clone () from /lib/libc.so.6
#5 0x0000000000000000 in ?? ()
For some people, the first time you run main, it doesn't segfault but also doesn't print anything. Then the second time you run main, it will segfault then.
Compiling with ghc does result in the right (non-segfaulting) behaviour, both with -threaded and without.
For me, this is with 6.8.2, but Igloo confirmed that it segfaults HEAD too.
Trac metadata
Trac field | Value |
---|---|
Version | 6.8.2 |
Type | Bug |
TypeOfFailure | OtherFailure |
Priority | normal |
Resolution | Unresolved |
Component | Runtime System |
Test case | |
Differential revisions | |
BlockedBy | |
Related | |
Blocking | |
CC | |
Operating system | Linux |
Architecture | x86_64 (amd64) |