Bug 1837154 - 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)
Summary: if ever occurred: memory overflow / configuration value "core.packedGitLimit"...
Keywords:
Status: CLOSED WONTFIX
Alias: None
Product: Red Hat Enterprise Linux 6
Classification: Red Hat
Component: git
Version: 6.10
Hardware: Unspecified
OS: Unspecified
unspecified
unspecified
Target Milestone: rc
: ---
Assignee: Ondřej Pohořelský
QA Contact: qe-baseos-daemons
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2020-05-19 00:13 UTC by Thomas Bruecker
Modified: 2020-05-21 07:34 UTC (History)
1 user (show)

Fixed In Version:
Doc Type: If docs needed, set a value
Doc Text:
Clone Of:
Environment:
Last Closed: 2020-05-20 11:54:19 UTC
Target Upstream Version:


Attachments (Terms of Use)
Patch that must be applied to "'config.c" (and then re-"make"...) (356 bytes, text/plain)
2020-05-19 00:13 UTC, Thomas Bruecker
no flags Details

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.


Note You need to log in before you can comment on or make changes to this bug.