Opened 6 years ago

Closed 6 years ago

Last modified 6 years ago

#2231 closed bug (duplicate)

ASSERT failed! file typecheck/TcMType.lhs line 442 t_a7Fa{tv} [tau]

Reported by: guest Owned by: simonpj
Priority: normal Milestone: 6.10 branch
Component: Compiler (Type checker) Version: 6.8.2
Keywords: Cc: matthew@…
Operating System: Unknown/Multiple Architecture: Unknown/Multiple
Type of failure: Difficulty: Unknown
Test Case: Blocked By:
Blocking: Related Tickets:

Description

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.

Attachments (1)

breakghc.tgz (37.3 KB) - added by guest 6 years ago.

Download all attachments as: .zip

Change History (20)

Changed 6 years ago by guest

comment:1 Changed 6 years ago by guest

  • Cc Matthew Sackman <matthew@…> added

comment:2 Changed 6 years ago by guest

I think the most important line out of this afternoon's #ghc discussion is:
05:43PM <Igloo> OK, tso->why_blocked is 56139, so it's definitely caused by corruption from somewhere

comment:3 Changed 6 years ago by guest

from ghc 6.8.2 with -DDEBUG

*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.
<interactive>: internal error: ASSERTION FAILED: file RaiseAsync.c, line 551

    (GHC version 6.8.2 for x86_64_unknown_linux)
    Please report this as a GHC bug:  http://www.haskell.org/ghc/reportabug

Program received signal SIGABRT, Aborted.
[Switching to Thread 0x41001950 (LWP 9533)]
0x00002b1b9b4e31d5 in raise () from /lib/libc.so.6
(gdb) bt
#0  0x00002b1b9b4e31d5 in raise () from /lib/libc.so.6
#1  0x00002b1b9b4e4680 in abort () from /lib/libc.so.6
#2  0x0000000001684308 in rtsFatalInternalErrorFn (s=0x179d658 "ASSERTION FAILED: file %s, line %u\n", ap=0x41000bb0) at RtsMessages.c:164
#3  0x0000000001683ecc in barf (s=0x179d658 "ASSERTION FAILED: file %s, line %u\n") at RtsMessages.c:40
#4  0x0000000001683f26 in _assertFail (filename=0x17ab104 "RaiseAsync.c", linenum=551) at RtsMessages.c:55
#5  0x00000000016afd7e in performBlockedException (cap=0x1ba6120, source=0x2b1b9be8ac58, target=0x2b1b9b889000) at RaiseAsync.c:551
#6  0x00000000016afc77 in maybePerformBlockedException (cap=0x1ba6120, tso=0x2b1b9b889000) at RaiseAsync.c:526
#7  0x000000000168e88d in threadPaused (cap=0x1ba6120, tso=0x2b1b9b889000) at ThreadPaused.c:195
#8  0x000000000167b3d7 in interpretBCO (cap=0x1ba6120) at Interpreter.c:741
#9  0x00000000016878c7 in schedule (initialCapability=0x1ba6120, task=0x1bc3400) at Schedule.c:628
#10 0x0000000001689901 in workerStart (task=0x1bc3400) at Schedule.c:2528
#11 0x00002b1b9b29d017 in start_thread () from /lib/libpthread.so.0
#12 0x00002b1b9b5775bd in clone () from /lib/libc.so.6
#13 0x0000000000000000 in ?? ()

comment:4 Changed 6 years ago by guest

  • Cc "Matthew Sackman" added; Matthew Sackman removed

And now with +RTS -DS -C0 -V0:

Starting program: /usr/local/lib/ghc-6.8.2/ghc-6.8.2 -B/usr/local/lib/ghc-6.8.2 --interactive +RTS -DS -C0 -V0 -RTS Control/Concurrent/Session/Queens.hs
[Thread debugging using libthread_db enabled]
[New Thread 0x2b5545f39490 (LWP 11372)]
[New Thread 0x40800950 (LWP 11375)]
[New Thread 0x41001950 (LWP 11376)]
GHCi, version 6.8.2: http://www.haskell.org/ghc/  :? for help
Warning: Freeing non-allocated memory at 0x1ba9850
Warning: Freeing non-allocated memory at 0x1ba7820
Loading package base ... linking ... done.
[ 1 of 12] Compiling Control.Concurrent.Session.Bool ( Control/Concurrent/Session/Bool.hs, interpreted )
[ 2 of 12] Compiling Control.Concurrent.Session.Number ( Control/Concurrent/Session/Number.hs, interpreted )
[ 3 of 12] Compiling Control.Concurrent.Session.List ( Control/Concurrent/Session/List.hs, interpreted )
[ 4 of 12] Compiling Control.Concurrent.Session.Map ( Control/Concurrent/Session/Map.hs, interpreted )
[ 5 of 12] Compiling Control.Concurrent.Session.SessionType ( Control/Concurrent/Session/SessionType.hs, interpreted )
[ 6 of 12] Compiling Control.Concurrent.Session.SMonad ( Control/Concurrent/Session/SMonad.hs, interpreted )
[ 7 of 12] Compiling Control.Concurrent.Session.Runtime ( Control/Concurrent/Session/Runtime.hs, interpreted )
[ 8 of 12] Compiling Control.Concurrent.Session.Pid ( Control/Concurrent/Session/Pid.hs, interpreted )
[ 9 of 12] Compiling Control.Concurrent.Session.Interleaving ( Control/Concurrent/Session/Interleaving.hs, interpreted )
[10 of 12] Compiling Control.Concurrent.Session.SessionTypeMonad ( Control/Concurrent/Session/SessionTypeMonad.hs, interpreted )
[11 of 12] Compiling Control.Concurrent.Session ( Control/Concurrent/Session.hs, interpreted )
[12 of 12] Compiling Control.Concurrent.Session.Queens ( Control/Concurrent/Session/Queens.hs, interpreted )
Ok, modules loaded: Control.Concurrent.Session, Control.Concurrent.Session.SessionTypeMonad, Control.Concurrent.Session.Queens, Control.Concurrent.Session.SMonad, Control.Concurrent.Session.SessionType, Control.Concurrent.Session.Number, Control.Concurrent.Session.Bool, Control.Concurrent.Session.List, Control.Concurrent.Session.Interleaving, Control.Concurrent.Session.Pid, Control.Concurrent.Session.Runtime, Control.Concurrent.Session.Map.
*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.
<interactive>: internal error: ASSERTION FAILED: file Schedule.c, line 674

    (GHC version 6.8.2 for x86_64_unknown_linux)
    Please report this as a GHC bug:  http://www.haskell.org/ghc/reportabug

Program received signal SIGABRT, Aborted.
[Switching to Thread 0x41001950 (LWP 11376)]
0x00002b5545c211d5 in raise () from /lib/libc.so.6
(gdb) bt
#0  0x00002b5545c211d5 in raise () from /lib/libc.so.6
#1  0x00002b5545c22680 in abort () from /lib/libc.so.6
#2  0x0000000001684308 in rtsFatalInternalErrorFn (s=0x179d658 "ASSERTION FAILED: file %s, line %u\n", ap=0x41000fa0) at RtsMessages.c:164
#3  0x0000000001683ecc in barf (s=0x179d658 "ASSERTION FAILED: file %s, line %u\n") at RtsMessages.c:40
#4  0x0000000001683f26 in _assertFail (filename=0x179df4b "Schedule.c", linenum=674) at RtsMessages.c:55
#5  0x0000000001687a52 in schedule (initialCapability=0x1ba6120, task=0x1bc3550) at Schedule.c:674
#6  0x0000000001689901 in workerStart (task=0x1bc3550) at Schedule.c:2528
#7  0x00002b55459db017 in start_thread () from /lib/libpthread.so.0
#8  0x00002b5545cb55bd in clone () from /lib/libc.so.6
#9  0x0000000000000000 in ?? ()

comment:5 Changed 6 years ago by guest

  • Cc matthew@… added; "Matthew Sackman" <matthew@…> removed

comment:6 Changed 6 years ago by igloo

  • Difficulty set to Unknown
  • Milestone set to 6.8.3

comment:7 Changed 6 years ago by igloo

  • Owner set to igloo

comment:8 Changed 6 years ago by igloo

I can't reproduce this on i386/Linux.

comment:9 Changed 6 years ago by simonmar

  • Priority changed from normal to high

comment:10 Changed 6 years ago by simonmar

  • Owner changed from igloo to simonmar

comment:11 Changed 6 years ago by simonmar

Using the latest 6.8.3 code with DEBUG on, I get an assertion failure:

/64playpen/simonmar/2231 > ~/nightly-stable/compiler/stage2/ghc-inplace --make Control/Concurrent/Session/Queens.hs       
[ 1 of 12] Compiling Control.Concurrent.Session.SMonad ( Control/Concurrent/Session/SMonad.hs, Control/Concurrent/Session/SMonad.o )
[ 2 of 12] Compiling Control.Concurrent.Session.Bool ( Control/Concurrent/Session/Bool.hs, Control/Concurrent/Session/Bool.o )
[ 3 of 12] Compiling Control.Concurrent.Session.Number ( Control/Concurrent/Session/Number.hs, Control/Concurrent/Session/Number.o )
[ 4 of 12] Compiling Control.Concurrent.Session.List ( Control/Concurrent/Session/List.hs, Control/Concurrent/Session/List.o )
[ 5 of 12] Compiling Control.Concurrent.Session.SessionType ( Control/Concurrent/Session/SessionType.hs, Control/Concurrent/Session/SessionType.o )
[ 6 of 12] Compiling Control.Concurrent.Session.Runtime ( Control/Concurrent/Session/Runtime.hs, Control/Concurrent/Session/Runtime.o )
ghc-6.8.2.20080601: panic! (the 'impossible' happened)
  (GHC version 6.8.2.20080601 for x86_64-unknown-linux):
        ASSERT failed! file typecheck/TcMType.lhs line 442 t_a7Fa{tv} [tau]

Please report this as a GHC bug:  http://www.haskell.org/ghc/reportabug

Since this might be related to the resulting crash, I'll confer with Simon PJ before debugging further.

comment:12 Changed 6 years ago by simonmar

  • Owner changed from simonmar to igloo
  • Type changed from bug to merge

I've fixed the crash:

Mon Jun  2 07:37:26 PDT 2008  Simon Marlow <marlowsd@gmail.com>
  * FIX #2231: add missing stack check when applying a PAP

The assertion failure in the type checker is still there and appears to be unrelated. We have no evidence that it is actually causing a problem, -dcore-lint still passes,

Ian: please merge, then re-assign to Simon and move the ticket to the 6.10 milestone.

comment:13 Changed 6 years ago by igloo

  • Milestone changed from 6.8.3 to 6.10 branch
  • Owner changed from igloo to simonpj

Merged

comment:14 Changed 6 years ago by igloo

  • Type changed from merge to bug

comment:15 Changed 6 years ago by igloo

  • Summary changed from GHC RTS Segfault to ASSERT failed! file typecheck/TcMType.lhs line 442 t_a7Fa{tv} [tau]

comment:16 Changed 6 years ago by simonmar

  • Architecture changed from x86_64 (amd64) to Multiple
  • Component changed from Runtime System to Compiler (Type checker)
  • Operating System changed from Linux to Multiple
  • Priority changed from high to normal

comment:17 Changed 6 years ago by simonpj

  • Resolution set to duplicate
  • Status changed from new to closed

I think this is a duplicate of #2212. I'm going to close this one, and point to it from #2212 for testing.

(The line number difference in the ASSERT failure is just 6.8 vs 6.9.

Simon

comment:18 Changed 6 years ago by simonmar

  • Architecture changed from Multiple to Unknown/Multiple

comment:19 Changed 6 years ago by simonmar

  • Operating System changed from Multiple to Unknown/Multiple
Note: See TracTickets for help on using tickets.