Bug 985256 - Rsyslog (5.8.10-2.el6) memory leak
Rsyslog (5.8.10-2.el6) memory leak
Product: Red Hat Enterprise Linux 6
Classification: Red Hat
Component: rsyslog (Show other bugs)
x86_64 Linux
unspecified Severity medium
: rc
: ---
Assigned To: Tomas Heinrich
BaseOS QE Security Team
Depends On:
  Show dependency treegraph
Reported: 2013-07-17 04:07 EDT by gregory.nuyttens
Modified: 2016-09-20 00:51 EDT (History)
2 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2013-07-24 07:45:13 EDT
Type: Bug
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)

  None (edit)
Description gregory.nuyttens 2013-07-17 04:07:37 EDT
Description of problem:
In rsyslog we can resets all configuration variables to their default value with the global value $ResetConfigVariables but in the module code of imfile we have that (rsyslog-5.8.10-6.el6.src.rpm) we have that:

static rsRetVal resetConfigVariables(uchar __attribute__((unused)) *pp, void __attribute__((unused)) *pVal)

	if(pszFileName != NULL) {
		pszFileName = NULL;

	if(pszFileTag != NULL) {
		pszFileTag = NULL;
	if(pszStateFile != NULL) {
		pszFileTag = NULL;

	/* set defaults... */
	iPollInterval = 10;
	iFacility = 128; /* local0 */
	iSeverity = 5;  /* notice, as of rfc 3164 */
	readMode = 0;
	pBindRuleset = NULL;


	if(pszStateFile != NULL) {
		pszFileTag = NULL;

seems to be a copy/paste error. 

Version-Release number of selected component (if applicable):
All 5.* versions (also be reproducible on Redhat Enterprise Linux 5 with package rsyslog5)

Actual results:
	if(pszStateFile != NULL) {
		pszFileTag = NULL;

Expected results:
	if(pszStateFile != NULL) {
		pszStateFile = NULL;

Grégory Nuyttens
Smals - Linux System Engineer
Tel +32 2/787 58 79
Comment 2 Tomas Heinrich 2013-07-23 11:50:17 EDT
Hello Gregory, thanks for the report.

The code is clearly wrong, but I can't see the leak in valgrind. From looking at the code it seems that there's now way the value can be leaked. There's one possible negative side effect that a subsequent $InputRunFileMonitor would reuse the value used in the previous one if no other value is defined, but that can be considered an error in the configuration.

So I'm inclined not to patch this as not to break something else. Do you experience some negative effects of the current status?
Comment 3 gregory.nuyttens 2013-07-24 04:00:55 EDT
Hi Tomas,

I'm agree with you and I don't have at this time bad experience about this *bug*.
If I encounter some negative effects, I will come back to you :-)

I believe that we can consider this report only for a "better" code in next versions.

Thanks for your consideration.
Comment 4 Tomas Heinrich 2013-07-24 07:45:13 EDT
Thanks for confirmation. Feel free to reopen if anything pops up.

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