#8933 closed bug (fixed)

process007: internal error: checkStackFrame: weird activation record found on stack

Reported by: trommler Owned by:
Priority: normal Milestone: 7.8.3
Component: Compiler Version: 7.8.1-rc2
Keywords: ppc Cc: simonmar
Operating System: Linux Architecture: Unknown/Multiple
Type of failure: Runtime crash Test Case: process007
Blocked By: Blocking: #8819
Related Tickets: #8819 Differential Revisions:

Description

On an unregisterised compiler process007 segfaults in all WAYS.

Here is a stack trace from a run with +RTS -DS on an x86_64 machine:

 Starting program: /home/trp/research/ghc-unreg/ghc-7.8/libraries/process/tests/process007 +RTS -DS
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/lib64/libthread_db.so.1".
cap 0: initialised
process007: internal error: checkStackFrame: weird activation record found on stack (0x7ffff69050b8 281051976).
    (GHC version 7.8.0.20140324 for x86_64_unknown_linux)
    Please report this as a GHC bug:  http://www.haskell.org/ghc/reportabug

Program received signal SIGABRT, Aborted.
0x00007ffff6a95849 in raise () from /lib64/libc.so.6
(gdb) where
#0  0x00007ffff6a95849 in raise () from /lib64/libc.so.6
#1  0x00007ffff6a96cd8 in abort () from /lib64/libc.so.6
#2  0x00000000008172af in rtsFatalInternalErrorFn (
    s=0x894080 "checkStackFrame: weird activation record found on stack (%p %d).", ap=0x7fffffffd968) at rts/RtsMessages.c:170
#3  0x0000000000816ee7 in barf (
    s=0x894080 "checkStackFrame: weird activation record found on stack (%p %d).") at rts/RtsMessages.c:42
#4  0x00000000008355e2 in checkStackFrame (c=0x7ffff69050b8)
    at rts/sm/Sanity.c:165
#5  0x000000000083560a in checkStackChunk (sp=0x7ffff69050b8, 
    stack_end=0x7ffff6905390) at rts/sm/Sanity.c:177
#6  0x0000000000836100 in checkSTACK (stack=0x7ffff6905000)
    at rts/sm/Sanity.c:497
#7  0x0000000000836254 in checkTSO (tso=0x7ffff6905390) at rts/sm/Sanity.c:535
#8  0x000000000082625a in threadStackOverflow (cap=0xd79740 <MainCapability>, 
    tso=0x7ffff6905390) at rts/Threads.c:500
#9  0x000000000082226a in schedule (
    initialCapability=0xd79740 <MainCapability>, task=0xd9a4e0)
    at rts/Schedule.c:528
#10 0x00000000008236b3 in scheduleWaitThread (tso=0x7ffff6905390, ret=0x0, 
    pcap=0x7fffffffdcc0) at rts/Schedule.c:2346
#11 0x0000000000824d63 in rts_evalLazyIO (cap=0x7fffffffdcc0, 
    p=0xbd4da0 <ZCMain_main_closure>, ret=0x0) at rts/RtsAPI.c:500
#12 0x00000000008272de in real_main () at rts/RtsMain.c:63
#13 0x00000000008273d1 in hs_main (argc=3, argv=0x7fffffffde48, 
    main_closure=0xbd4da0 <ZCMain_main_closure>, rts_config=...)
    at rts/RtsMain.c:114
#14 0x000000000040849f in main ()

Running without the RTS flags:

Program received signal SIGSEGV, Segmentation fault.
0x00000000008307ed in StgRun (f=0xd79758b8e5894855, 
    basereg=0xd79758 <MainCapability+24>) at rts/StgCRun.c:81
81              f = (StgFunPtr) (f)();
(gdb) where
#0  0x00000000008307ed in StgRun (f=0xd79758b8e5894855, 
    basereg=0xd79758 <MainCapability+24>) at rts/StgCRun.c:81
#1  0x0000000000822022 in schedule (
    initialCapability=0xd79740 <MainCapability>, task=0xd9a470)
    at rts/Schedule.c:463
#2  0x00000000008236b3 in scheduleWaitThread (tso=0x7ffff6905390, ret=0x0, 
    pcap=0x7fffffffdcd0) at rts/Schedule.c:2346
#3  0x0000000000824d63 in rts_evalLazyIO (cap=0x7fffffffdcd0, 
    p=0xbd4da0 <ZCMain_main_closure>, ret=0x0) at rts/RtsAPI.c:500
#4  0x00000000008272de in real_main () at rts/RtsMain.c:63
#5  0x00000000008273d1 in hs_main (argc=1, argv=0x7fffffffde58, 
    main_closure=0xbd4da0 <ZCMain_main_closure>, rts_config=...)
    at rts/RtsMain.c:114
#6  0x000000000040849f in main ()

The value of f in StgRun looks strange the first three bytes are the same as basereg 0xd79758.

Change History (9)

comment:1 Changed 15 months ago by trommler

Using the RC2 bindist from haskell.org I confirmed the test also segfaults on powerpc64 but only in WAYS normal,hpc,threaded1,dyn,optllvm

I did not observe the strange pattern in the parameters to StgRun that I saw on x86_64.

comment:2 Changed 15 months ago by trommler

  • Blocking 8819 added

comment:3 Changed 15 months ago by simonmar

  • Cc simonmar added

comment:4 Changed 14 months ago by thoughtpolice

  • Keywords ppc added

comment:5 Changed 14 months ago by thoughtpolice

  • Status changed from new to infoneeded

comment:6 Changed 14 months ago by trommler

ghc 7.8.2 unregisterised on x86_64 Linux:

$ make TEST=process007
[...]
Unexpected results from:
TEST="process007"

OVERALL SUMMARY for test run started at Tue Apr 29 13:31:11 2014 CEST
 0:00:14 spent to go through
    3918 total tests, which gave rise to
   15288 test cases, of which
   15280 were skipped

       0 had missing libraries
       3 expected passes
       0 expected failures

       0 caused framework failures
       0 unexpected passes
       5 unexpected failures

Unexpected failures:
   ../../libraries/process/tests  process007 [bad exit code] (normal,hpc,threaded1,dyn,optllvm)

make[1]: Leaving directory `/home/trp/research/ghc-unreg/ghc-7.8.2/testsuite/tests'

I'll post ppc64 later today.

comment:7 follow-up: Changed 14 months ago by trommler

You probably wanted me to check with HEAD, sorry.

On x86_64 (unregisterised) process007 passes in HEAD plus my patch for #9055.
I will check powerpc64 tonight.

comment:8 in reply to: ↑ 7 Changed 14 months ago by trommler

Replying to trommler:

You probably wanted me to check with HEAD, sorry.

On x86_64 (unregisterised) process007 passes in HEAD plus my patch for #9055.
I will check powerpc64 tonight.

process007 passes on Linux powerpc64.

Last edited 14 months ago by trommler (previous) (diff)

comment:9 Changed 14 months ago by trommler

  • Resolution set to fixed
  • Status changed from infoneeded to closed

Test process007 passes with tip of ghc-7.8 branch on powerpc64, too.

Thanks for the fix Simon M!

Closing the ticket.

Note: See TracTickets for help on using tickets.