Skip to content
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

Closed
vicuna opened this issue Jan 17, 2013 · 5 comments
Closed

Fork stuck when big memory use and profile option for compilation #5893

vicuna opened this issue Jan 17, 2013 · 5 comments

Comments

@vicuna
Copy link

vicuna commented Jan 17, 2013

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

@vicuna
Copy link
Author

vicuna commented Jan 17, 2013

Comment author: johan.mazel

I forgot to add that this only happens with native compilation.
Bytecode compilation seems to not experience this problem.

@vicuna
Copy link
Author

vicuna commented Jan 17, 2013

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) ---
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.

@vicuna
Copy link
Author

vicuna commented Jun 28, 2013

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.

@vicuna
Copy link
Author

vicuna commented Aug 1, 2013

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.

@vicuna
Copy link
Author

vicuna commented Aug 2, 2013

Comment author: berenger

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?!

@vicuna vicuna closed this as completed Dec 11, 2015
@vicuna vicuna added this to the 4.01.0 milestone Mar 14, 2019
@vicuna vicuna added the bug label Mar 20, 2019
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

1 participant