Bug 61386 - fprintf memory leak
fprintf memory leak
Product: Red Hat Linux
Classification: Retired
Component: glibc (Show other bugs)
i386 Linux
medium Severity medium
: ---
: ---
Assigned To: Jakub Jelinek
Brian Brock
Depends On:
  Show dependency treegraph
Reported: 2002-03-18 17:17 EST by Need Real Name
Modified: 2016-11-24 10:05 EST (History)
1 user (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2002-12-15 14:40:17 EST
Type: ---
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 Need Real Name 2002-03-18 17:17:40 EST
Description of Problem:

fprintf leaks memory by the length of data written to a file. It does not happen on redhat 6.2.

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

How Reproducible:

It's reproducible. 

Steps to Reproduce:

Actual Results:

Expected Results:

Additional Information:
Comment 1 Need Real Name 2002-03-18 17:46:40 EST
Correction: The 'memory leak' size is not the length of data, but about 4k per fprintf according to "vmstat -n 1".

My small test program is following:

char log_message[256]="";      
FILE *rep;                    

int main( int argc, char *argv[] )
int rc=0;
int i=0;
int count=0; 
char log_message[256]="";

count = atoi(argv[1]);
rep = fopen("service.log", "a+");                 
if (rep == NULL ){                              
    printf (log_message, " ** Unable to open service.log"); 
for (i=0;i<count;i++){
  fprintf( rep, "%05d%s\n", i, log_message);  

if (rc){                              
   printf (" ** Unable to close service.log");  
Comment 2 Arjan van de Ven 2002-03-19 11:56:06 EST
1) fprintf() is not a kernel systemcall
2) Welcome to disk caching
Comment 3 Need Real Name 2002-03-19 13:06:12 EST
Correction again: The size of memory leak is about 4k from 10 fprintf's approximately.
Comment 4 Jakub Jelinek 2002-03-27 14:50:32 EST
Sorry, I don't see any leaks.
I've commented out the sleep call and run it under strace. After startup
there are no other syscalls than write until the loop ends (see strace output).
If libc leaked memory, there would be mmap or brk syscalls in between.
Comment 5 Need Real Name 2002-04-18 15:51:23 EDT
Thank you for your research. I saw 4k memory leak after 10-15 seconds. I am not sure how long you ran strace.  I tested 'write' system call instead 
of 'fprintf. It showed same memory leak also. I am still wondering why this problem does not happen on redhat 6.2 machines. (tried two redhat 6.2 
machines.) Do  you think my redhat 7.1 configuration about 'file write' is incorrect? Would you give me any suggestions to specify good values for 
the 'file write'.
Comment 6 Need Real Name 2002-04-18 16:41:44 EDT
Found a web site describing fprintf memory leak, but  the suggested solution does not work for me. I don't know if  their system is linux. The site has 
the title, "[uCsimm] General memory problem".
Tested printf instead of  fprintf. No memory leak was shown.  

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