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

Calling Gc.major_slice stalls gc'ing #7813

Closed
vicuna opened this issue Jun 25, 2018 · 4 comments · Fixed by #9955
Closed

Calling Gc.major_slice stalls gc'ing #7813

vicuna opened this issue Jun 25, 2018 · 4 comments · Fixed by #9955
Assignees
Labels

Comments

@vicuna
Copy link

vicuna commented Jun 25, 2018

Original bug ID: 7813
Reporter: anders.fugmann
Status: new
Resolution: open
Priority: normal
Severity: minor
Version: 4.06.1
Category: runtime system and C interface
Monitored by: @nojb

Bug description

When only allocating data on the major heap, and continuously calling Gc.major_slice, the gc gets into a state where it stops collecting.

The attached test exposes the problem, and results in OOM after a while.

Removing the call to Gc.major_slice, or extending the test to do allocations on the minor heap avoids the gc stall, and memory pressure stabilizes to allow the test to run forever.

Steps to reproduce

The attached test exposes the problem on 4.06.1 and 4.07-trunk.

File attachments

@vicuna
Copy link
Author

vicuna commented Jun 25, 2018

Comment author: anders.fugmann

test file leak.ml does not exhibit the problem as it does a minor heap allocation also. Uploaded leak2.ml which does expose the bug.

@vicuna
Copy link
Author

vicuna commented Jun 25, 2018

Comment author: @ivg

I've looked into it and it looks like a race condition, since caml_major_collection_slice resets caml_allocated_words to zero, even if no work is done and it couldn't be done until the minor heap is emptied, which is not possible because the GC is not triggered since there are no minor heap allocations in the example program and alloc_share doesn't trigger the GC since caml_allocated_words doesn't grow. Please, follow the link below, for the detailed explanation:

https://discuss.ocaml.org/t/bug-in-gc-major-slice/2174/2?u=ivg

@vicuna vicuna added the stdlib label Mar 14, 2019
@github-actions
Copy link

github-actions bot commented May 7, 2020

This issue has been open one year with no activity. Consequently, it is being marked with the "stale" label. What this means is that the issue will be automatically closed in 30 days unless more comments are added or the "stale" label is removed. Comments that provide new information on the issue are especially welcome: is it still reproducible? did it appear in other contexts? how critical is it? etc.

@github-actions github-actions bot added the Stale label May 7, 2020
@ivg
Copy link
Member

ivg commented May 7, 2020

The issue is still clearly reproducible. Just in case, the summary of the issue: GC is not triggered when a program allocates only large objects.

The following program (attached to the issue report, repeated here for visibility) will eat all the memory.

let rec alloc = function
  | 100000 ->
    Printf.printf "Allocated words: %d\n%!" (Gc.stat ()).Gc.live_words;
    alloc 0
  | n ->
    Bytes.create 2048 |> ignore;
    Gc.major_slice 0 |> ignore;
    alloc (n + 1)

let () = alloc 0

and the output:

$ ocamlbuild poc.native --
Finished, 4 targets (0 cached) in 00:00:00.
Allocated words: 25800000
Allocated words: 51600000
Allocated words: 77400000
Allocated words: 103200000
Allocated words: 129000000
Allocated words: 154800000
Allocated words: 180600000
Allocated words: 206400000
Allocated words: 232200000
Allocated words: 258000000
Allocated words: 283800000
Allocated words: 309600000
Allocated words: 335400000
Allocated words: 361200000
Allocated words: 387000000
Allocated words: 412800000
Allocated words: 438600000
Allocated words: 464400000
Allocated words: 490200000
Allocated words: 516000000
Killed

Although the code in the trunk has changed a bit due to the reentrant runtime changes, the write-through on Discuss is still actual, just some files have moved.

@damiendoligez damiendoligez self-assigned this May 7, 2020
damiendoligez added a commit to damiendoligez/ocaml that referenced this issue Oct 2, 2020
major GC cycle instead of just calling caml_major_collection_slice.
fixes ocaml#7813
damiendoligez added a commit to damiendoligez/ocaml that referenced this issue Nov 3, 2020
major GC cycle instead of just calling caml_major_collection_slice.
fixes ocaml#7813
damiendoligez added a commit to damiendoligez/ocaml that referenced this issue Nov 3, 2020
major GC cycle instead of just calling caml_major_collection_slice.
fixes ocaml#7813
Octachron added a commit that referenced this issue Nov 24, 2020
Octachron added a commit that referenced this issue Nov 24, 2020
Fix #7813 (major GC fails to start)

(cherry picked from commit 3d6dc0f)
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

Successfully merging a pull request may close this issue.

3 participants