New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Fork stuck when big memory use and profile option for compilation #5893
Comments
Comment author: johan.mazel I forgot to add that this only happens with native compilation. |
Comment author: berenger Here is some part of an strace of a program that was affected by this possible bug: --- SIGPROF (Profiling timer expired) @ 0 (0) ---
|
Comment author: @damiendoligez 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. |
Comment author: @xavierleroy 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. |
Comment author: berenger Apparently, the bug is fixed in RHEL kernels: cf. Why was this not fixed for all kernels?! |
Original bug ID: 5893
Reporter: johan.mazel
Status: closed (set by @xavierleroy on 2015-12-11T18:21:22Z)
Resolution: not a bug
Priority: normal
Severity: minor
Platform: Linux
OS: Debian
OS Version: Testing
Version: 4.00.0
Target version: 4.01.0+dev
Category: back end (clambda to assembly)
Bug description
Fork 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 reproduce
I 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.
File attachments
The text was updated successfully, but these errors were encountered: