Bug 1837154

Summary: if ever occurred: memory overflow / configuration value "core.packedGitLimit" has no effect at all (--> no limit) if set to 2g(e.g.) or greater(in any case)
Product: Red Hat Enterprise Linux 6 Reporter: Thomas Bruecker <public>
Component: gitAssignee: Ondřej Pohořelský <opohorel>
Status: CLOSED WONTFIX QA Contact: qe-baseos-daemons
Severity: unspecified Docs Contact:
Priority: unspecified    
Version: 6.10CC: pcahyna
Target Milestone: rc   
Target Release: ---   
Hardware: Unspecified   
OS: Unspecified   
Whiteboard:
Fixed In Version: Doc Type: If docs needed, set a value
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2020-05-20 11:54:19 UTC Type: Bug
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Attachments:
Description Flags
Patch that must be applied to "'config.c" (and then re-"make"...) none

Description Thomas Bruecker 2020-05-19 00:13:41 UTC
Created attachment 1689723 [details]
Patch that must be applied to "'config.c" (and then re-"make"...)

Description of problem:
If "core.packedGitLimit" is set to to 2g(e.g.) or greater(in any case) it
has no effect anymore --> the physical memory, that git uses, may grow until
git or other processes are killed due to memory overflow.

Version-Release number of selected component (if applicable):
At least (I come from CentOS, so, maybe the version# is not exact)
1.7.1.10.el6... and (so I guess) any older version.

How reproducible / Steps to Reproduce
'you must have opened enough packages / a package that is big enough'.
<-- but why bother with this; according to my patch, the possible occurrence of
the bug is evident.

Actual results: see e.g. "Description of problem" <-- but why bother...

Additional info:
In e.g. upstream version 2.26.2 the problem is solved exactly in the same way as
my patch does.

Comment 2 Ondřej Pohořelský 2020-05-20 11:54:19 UTC
Red Hat Enterprise Linux 6 is in the Maintenance Support 2 Phase. During the Maintenance Support 2 Phase, Critical impact Security Advisories (RHSAs) and selected Urgent Priority Bug Fix Advisories (RHBAs) may be released as they become available.
The official life cycle policy can be reviewed here:
http://redhat.com/rhel/lifecycle
This issue does not meet the inclusion criteria for the Maintenance Support 2 Phase and will be marked as CLOSED/WONTFIX. If this remains a critical requirement, please contact Red Hat Customer Support to request a re-evaluation of the issue, citing a clear business justification.  Red Hat Customer Support can be contacted via the Red Hat Customer Portal at the following URL:
https://access.redhat.com

Comment 3 Thomas Bruecker 2020-05-20 15:38:02 UTC
* Thank you and the redhat team for processing this bug report so quickly.
* My reason to report this bug, has just been, if someone else has a problem of this kind, it is not
  necessary, that someone else (e.g. from redhat) has to dig again for hours in the source code, to fix
  the problem (ok. maybe the redhat team works faster than I do ...).

Comment 4 Ondřej Pohořelský 2020-05-21 07:34:30 UTC
(In reply to Thomas Bruecker from comment #3)
> * Thank you and the redhat team for processing this bug report so quickly.
> * My reason to report this bug, has just been, if someone else has a problem
> of this kind, it is not
>   necessary, that someone else (e.g. from redhat) has to dig again for hours
> in the source code, to fix
>   the problem (ok. maybe the redhat team works faster than I do ...).

We are grateful for your contribution. Your patch looks correct.
But RHEL 6 is in the Maintenance Support 2 Phase, which means we make fixes for critical CVEs and other important fixes submitted through customer portal.