Opened 3 years ago

Closed 3 years ago

Last modified 3 years ago

#6071 closed bug (worksforme)

Compiled program segfaults

Reported by: stevecheckoway Owned by: simonmar
Priority: highest Milestone: 7.4.2
Component: Compiler Version: 7.0.4
Keywords: Cc:
Operating System: Linux Architecture: Unknown/Multiple
Type of failure: Runtime crash Test Case:
Blocked By: Blocking:
Related Tickets: Differential Revisions:

Description

When I run the bug program, it correctly computes 28 values (output lines 1 through 28) and on the 29th, it segfaults.

For some reason this program runs out of stack space; however if you compile it with -rtsopts and increase the size of the stack, it will segfault on the 29th.

This program is fairly slow. Compiled with -O4, it took 3 minutes to segfault and used more than 20 GB of RAM.

Attachments (1)

bug.hs (3.1 KB) - added by stevecheckoway 3 years ago.

Download all attachments as: .zip

Change History (4)

Changed 3 years ago by stevecheckoway

comment:1 Changed 3 years ago by simonmar

  • difficulty set to Unknown
  • Milestone set to 7.4.2
  • Owner set to simonmar
  • Priority changed from normal to highest
  • Type of failure changed from None/Unknown to Runtime crash

comment:2 Changed 3 years ago by simonmar

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

Not reproducible with 7.4.1:

$ ./6071 +RTS -K1g
1: 0/6204
2: 0/6204
3: 0/6204
4: 0/6204
5: 0/6204
6: 0/6204
7: 0/6204
8: 0/6204
9: 0/6204
10: 0/6204
11: 0/6204
12: 0/6204
13: 0/6204
14: 0/6204
15: 0/6204
16: 0/6204
17: 0/6204
18: 0/6204
19: 0/6204
20: 0/6204
21: 0/6204
22: 0/6204
23: 0/6204
24: 0/6204
25: 0/6204
26: 0/2449432
27: 0/5027767
28: 0/5027767
29: 0/10980733
526.17s real   495.15s user   28.53s system   99% ./6071 +RTS -K1g

Also tried with 7.0.3, which didn't crash (and was slower):

$ ./6071 +RTS -K1g                       
1: 0/6204
2: 0/6204
3: 0/6204
4: 0/6204
5: 0/6204
6: 0/6204
7: 0/6204
8: 0/6204
9: 0/6204
10: 0/6204
11: 0/6204
12: 0/6204
13: 0/6204
14: 0/6204
15: 0/6204
16: 0/6204
17: 0/6204
18: 0/6204
19: 0/6204
20: 0/6204
21: 0/6204
22: 0/6204
23: 0/6204
24: 0/6204
25: 0/6204
26: 0/2449432
27: 0/5027767
28: 0/5027767
29: 0/10980733
570.59s real   530.66s user   36.76s system   99% ./6071 +RTS -K1g

It could be a hardware problem - please try to reproduce it on a different machine.

comment:3 Changed 3 years ago by stevecheckoway

I don't have evidence that it's not a hardware problem, but I think this is an out of memory/swap situation interacting poorly with the runtime. I reimplemented my algorithm (the real one, not the pared down one here) in C++ and either it fails to allocate enough memory at some point (and thus throws an exception) or Linux's OOM killer kills the process.

I'm trying to arrange access to a nonidentical machine with which I can run the test program. Possibly increasing the tunableParameter will trigger the bug for you.

Note: See TracTickets for help on using tickets.