Mantis Bug Tracker

View Issue Details Jump to Notes ] Issue History ] Print ]
IDProjectCategoryView StatusDate SubmittedLast Update
0005893OCamlOCaml backend (code generation)public2013-01-17 06:512013-08-02 03:20
Reporterjohan.mazel 
Assigned To 
PrioritynormalSeverityminorReproducibilityalways
StatusresolvedResolutionno change required 
PlatformLinuxOSDebianOS VersionTesting
Product Version4.00.0 
Target Version4.01.0+devFixed in Version 
Summary0005893: Fork stuck when big memory use and profile option for compilation
DescriptionFork is stuck at execution when one uses a consequent amount of memory (in my case 8%) and the profile option is used during compilation.
When the fork call is stuck, the program uses 100% of one core.
Steps To ReproduceI made a small program that first create a big array called array1 that contains other arrays named array2. The size of those arrays can be chosen through the two mandatory parameters of the program.
In my case, the bug happens with array1 length = 1000 and array2 length = 200000.

This program is located in the joined tar archive along with _tags and makefile files.
TagsNo tags attached.
Attached Filestar file icon Fork_problem.tar [^] (10,240 bytes) 2013-01-17 06:51
c file icon forkbug.c [^] (681 bytes) 2013-08-01 14:30 [Show Content]

- Relationships

-  Notes
(0008766)
johan.mazel (reporter)
2013-01-17 07:04

I forgot to add that this only happens with native compilation.
Bytecode compilation seems to not experience this problem.
(0008767)
berenger (reporter)
2013-01-17 07:39

Here is some part of an strace of a program that was affected by this possible bug:

---
--- SIGPROF (Profiling timer expired) @ 0 (0) ---
rt_sigreturn(0x1b) = 140464321150976
clone(child_stack=0, flags=CLONE_CHILD_CLEARTID|CLONE_CHILD_SETTID|SIGCHLD, child_tidptr=0x7fc080ed19d0) = ? ERESTARTNOINTR (To be restarted)
--- SIGPROF (Profiling timer expired) @ 0 (0) ---
rt_sigreturn(0x1b) = 56
clone(child_stack=0, flags=CLONE_CHILD_CLEARTID|CLONE_CHILD_SETTID|SIGCHLD, child_tidptr=0x7fc080ed19d0) = ? ERESTARTNOINTR (To be restarted)
--- SIGPROF (Profiling timer expired) @ 0 (0) ---
rt_sigreturn(0x1b) = 56
clone(child_stack=0, flags=CLONE_CHILD_CLEARTID|CLONE_CHILD_SETTID|SIGCHLD, child_tidptr=0x7fc080ed19d0) = ? ERESTARTNOINTR (To be restarted)
--- SIGPROF (Profiling timer expired) @ 0 (0) ---
rt_sigreturn(0x1b) = 56
clone(child_stack=0, flags=CLONE_CHILD_CLEARTID|CLONE_CHILD_SETTID|SIGCHLD, child_tidptr=0x7fc080ed19d0) = ? ERESTARTNOINTR (To be restarted)
---

Hope this helps,
F.
(0009642)
doligez (administrator)
2013-06-28 18:23

Isn't it a bug in Linux? It looks like the profiling timer interrupts the fork() system call, which gets restarted, but then takes too much time and gets interrupted again by the profiling timer, leading to an infinite loop.
(0010063)
xleroy (administrator)
2013-08-01 14:32

I could reproduce the same problem with a C program compiled with gcc -pg. (See attached forkbug.c file.) The bug is not in OCaml.

Under Linux, "perf" is probably a better alternative to "ocamlopt -p" or "gcc -pg" for profiling executions.
(0010075)
berenger (reporter)
2013-08-02 03:20

Apparently, the bug is fixed in RHEL kernels:

cf.
https://bugzilla.redhat.com/show_bug.cgi?id=645528 [^]
and look for SIGPROF in the list of bugs fixed
here:
http://rhn.redhat.com/errata/RHSA-2011-1065.html [^]

Why was this not fixed for all kernels?!

- Issue History
Date Modified Username Field Change
2013-01-17 06:51 johan.mazel New Issue
2013-01-17 06:51 johan.mazel File Added: Fork_problem.tar
2013-01-17 07:04 johan.mazel Note Added: 0008766
2013-01-17 07:39 berenger Note Added: 0008767
2013-06-28 18:23 doligez Note Added: 0009642
2013-06-28 18:23 doligez Status new => acknowledged
2013-06-28 18:23 doligez Target Version => 4.01.0+dev
2013-08-01 14:30 xleroy File Added: forkbug.c
2013-08-01 14:32 xleroy Note Added: 0010063
2013-08-01 14:32 xleroy Status acknowledged => resolved
2013-08-01 14:32 xleroy Resolution open => no change required
2013-08-02 03:20 berenger Note Added: 0010075


Copyright © 2000 - 2011 MantisBT Group
Powered by Mantis Bugtracker