Description of problem:

When cloning or otherwise access a mercurial repository the process is killed by OOM-killer.

Version-Release number of selected component (if applicable):

git-2.28.0-1.fc33.x86_64

How reproducible:

Always

Steps to Reproduce:
1.  git clone hg::https://hg.mozilla.org/projects/nss

Actual results:

The process git-fast-import is killed by OOM-killer.  Using top I see that first the available core memory is used up and then the available swap memory is also used up, so no more memory is available.

Expected results:

The repository is cloned successfully.

Additional info:

It seem upstream has a fix:


commit 3f018ec716292b4d757385686f42f57af3bca685
Author: Jeff King <peff>
Date:   Thu Oct 15 11:38:49 2020 -0400

    fast-import: fix over-allocation of marks storage
    
    Fast-import stores its marks in a trie-like structure made of mark_set
    structs. Each struct has a fixed size (1024). If our id number is too
    large to fit in the struct, then we allocate a new struct which shifts
    the id number by 10 bits. Our original struct becomes a child node
    of this new layer, and the new struct becomes the top level of the trie.
    
    This scheme was broken by ddddf8d7e2 (fast-import: permit reading
    multiple marks files, 2020-02-22). Before then, we had a top-level
    "marks" pointer, and the push-down worked by assigning the new top-level
    struct to "marks". But after that commit, insert_mark() takes a pointer
    to the mark_set, rather than using the global "marks". It continued to
    assign to the global "marks" variable during the push down, which was
    wrong for two reasons:
    
      - we added a call in option_rewrite_submodules() which uses a separate
        mark set; pushing down on "marks" is outright wrong here. We'd
        corrupt the "marks" set, and we'd fail to correctly store any
        submodule mappings with an id over 1024.
    
      - the other callers passed "marks", but the push-down was still wrong.
        In read_mark_file(), we take the pointer to the mark_set as a
        parameter. So even though insert_mark() was updating the global
        "marks", the local pointer we had in read_mark_file() was not
        updated. As a result, we'd add a new level when needed, but then the
        next call to insert_mark() wouldn't see it! It would then allocate a
        new layer, which would also not be seen, and so on. Lookups for the
        lost layers obviously wouldn't work, but before we even hit any
        lookup stage, we'd generally run out of memory and die.
    
    Our tests didn't notice either of these cases because they didn't have
    enough marks to trigger the push-down behavior. The new tests in t9304
    cover both cases (and fail without this patch).
    
    We can solve the problem by having insert_mark() take a pointer-to-pointer
    of the top-level of the set. Then our push down can assign to it in a
    way that the caller actually sees. Note the subtle reordering in
    option_rewrite_submodules(). Our call to read_mark_file() may modify our
    top-level set pointer, so we have to wait until after it returns to
    assign its value into the string_list.
    
    Reported-by: Sergey Brester <serg.brester>
    Signed-off-by: Jeff King <peff>
    Signed-off-by: Junio C Hamano <gitster>