Opened 8 years ago

Closed 8 years ago

#3167 closed bug (fixed)

Segmentation fault with compacting GC, and multiple threads

Reported by: guest Owned by:
Priority: normal Milestone:
Component: Runtime System Version: 6.8.2
Keywords: Cc: manlio.perillo@…
Operating System: Unknown/Multiple Architecture: Unknown/Multiple
Type of failure: None/Unknown Test Case:
Blocked By: Blocking:
Related Tickets: Differential Rev(s):
Wiki Page:


In a program I have experienced a segmentation fault; not only that but also:

* tpp.c:63: __pthread_tpp_change_priority: Assertion `new_prio == -1 || (new_prio >= _sched_fifo_min_prio && new_prio <= __sched_fifo_max_prio)' failed.'

* internal error: removeThreadFromQueue: not found
    (GHC version 6.8.2 for i386_unknown_linux)
    Please report this as a GHC bug:

I have managed to write a program that reproduces the problem, it is in attachment.

  1. Compile with: $ghc --make -threaded -O2 main.hs
  2. Execute with: $./main +RTS -A128M -s -c -N4 -RTS 5000000 500

This should produce a segmentation fault (or one of the previous errors).

I strongly suspect that the cause is an uncaught stack overflow.

  • Executing the code with only 1 threads, there are no more problems.
  • Increasing the thread stack size (-k1M), there are no more problems.

If the problem is really an uncaught stack overflow, I'm rather sure that a more simple test can be written, to reproduce the problem.

I'm on Linux Debian Etch i386; GHC 6.8.2.

Attachments (1)

main.hs (4.5 KB) - added by guest 8 years ago.

Download all attachments as: .zip

Change History (4)

Changed 8 years ago by guest

Attachment: main.hs added

comment:1 Changed 8 years ago by guest


comment:2 Changed 8 years ago by dons

Summary: segmentation faultSegmentation fault with compacting GC, and multiple threads

Can't reproduce this with ghc 6.10.1.

It allocates about 2G and starts churning away happily:

$ ghc --make -O2 main.hs -threaded -fforce-recomp
[1 of 1] Compiling Main             ( main.hs, main.o )
Linking main ...

$ ./main +RTS -A128M -s -c -N4 -RTS 5000000 500  
./main 5000000 500 +RTS -A128M -s -c -N4 
processing 1
processing 126
processing 251
processing 2
processing 3
processing 4
processing 486
processing 487
processing 488
processing 489
processing 490
processing 491
processing 492
processing 493
processing 494
processing 495
processing 496
processing 497
processing 498
processing 499
processing 500

  15,191,954,480 bytes allocated in the heap
   1,847,859,512 bytes copied during GC
     738,284,008 bytes maximum residency (12 sample(s))
      15,017,912 bytes maximum slop
            3019 MB total memory in use (47 MB lost due to fragmentation)
  INIT  time    0.00s  (  0.03s elapsed)
  MUT   time   42.61s  ( 44.45s elapsed)
  GC    time   32.33s  ( 33.54s elapsed)
  EXIT  time    0.00s  (  0.10s elapsed)
  Total time   74.88s  ( 78.03s elapsed)

  %GC time      43.2%  (43.0% elapsed)

  Alloc rate    357,005,002 bytes per MUT second

  Productivity  56.8% of total user, 54.5% of total elapsed

Looks like it was fixed in GHC 6.10.x

comment:3 Changed 8 years ago by simonmar

difficulty: Unknown
Resolution: fixed
Status: newclosed

We fixed some serious parallel execution bugs since 6.8.2. Please re-open if you can reproduce it with 6.10.x.

Note: See TracTickets for help on using tickets.