Bug 167640 - un-efficient memory management cause segmentation fault
Summary: un-efficient memory management cause segmentation fault
Status: RESOLVED WORKSFORME
Alias: None
Product: valgrind
Classification: Developer tools
Component: memcheck (other bugs)
Version First Reported In: unspecified
Platform: unspecified Linux
: NOR normal
Target Milestone: ---
Assignee: Julian Seward
URL:
Keywords: investigated, triaged
Depends on:
Blocks:
 
Reported: 2008-07-29 06:45 UTC by Fisher Wu
Modified: 2018-11-12 16:03 UTC (History)
1 user (show)

See Also:
Latest Commit:
Version Fixed/Implemented In:
Sentry Crash Report:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Fisher Wu 2008-07-29 06:45:55 UTC
this is test program:
#include <stdio.h>
#include <stdlib.h>

int main( int argc, char **argv )
{
    #define MAX_NO 20
    #define MAX_TIME 50
    char *pt[MAX_NO], *tmp;
    size_t i, j, k, size_len[MAX_NO], size_add;
    
    
    for( i=0; i<100000; i++ )
    {
        for( j=0; j<MAX_NO; j++ )
        {
            size_add = rand();
            size_add %= 100000;    //  limit add size
            size_len[j] = 1920520 + size_add;
            pt[j] = (char*)malloc( size_len[j] );
        }
        for( k=0; k<MAX_TIME; k++ )
        {
            for( j=0; j<MAX_NO; j++ )
            {
                if( pt[j] != NULL )
                {
                    size_add = rand();
                    size_add %= 100000;    //  limit add size
                    tmp = pt[j];
                    size_len[j] += size_add;
                    tmp = (char*)realloc( tmp, size_len[j] );
                    if( tmp != NULL )
                    {
                        pt[j] = tmp;
                    }
                    else
                        printf( "realloc() fail\n" );
                }
            }
        }
        for( j=0; j<MAX_NO; j++ )
        {
            if( pt[j] != NULL )
                free( pt[j] );
        }
    }
    return 0;
}
====================================
this is result running by valgrind:
top - 12:37:25 up 101 days, 19:29,  2 users,  load average: 1.74, 1.53, 0.94
Tasks:  56 total,   2 running,  53 sleeping,   1 stopped,   0 zombie
Cpu(s): 44.3% us,  6.3% sy,  0.0% ni,  0.0% id, 48.7% wa,  0.7% hi,  0.0% si
Mem:    507796k total,   502548k used,     5248k free,      400k buffers
Swap:  1020116k total,    52392k used,   967724k free,     6272k cached

  PID USER      PR  NI  VIRT  RES  SHR S %CPU %MEM    TIME+  COMMAND
31561 fisherw   18   0 1770m 454m  860 R 49.6 91.6   0:09.39 valgrind
                                              ====   
================================
this is result running without valgrind:
top - 12:36:34 up 101 days, 19:28,  2 users,  load average: 2.65, 1.62, 0.93
Tasks:  56 total,   3 running,  52 sleeping,   1 stopped,   0 zombie
Cpu(s):  9.0% us, 91.0% sy,  0.0% ni,  0.0% id,  0.0% wa,  0.0% hi,  0.0% si
Mem:    507796k total,    93308k used,   414488k free,      884k buffers
Swap:  1020116k total,    60544k used,   959572k free,    13892k cached

  PID USER      PR  NI  VIRT  RES  SHR S %CPU %MEM    TIME+  COMMAND
31454 fisherw   25   0 72752  388  256 R 99.9  0.1   0:14.81 realloc
                                               ===
Comment 1 Julian Seward 2008-11-05 00:30:16 UTC
I can't reproduce this using the test program you supplied.
On x86_64, memcheck uses about 440MB total process size ("VIRT")
and on x86 it is about 410MB.  This is after several minutes
of running.
Comment 2 Fisher Wu 2008-11-06 04:03:00 UTC
Maybe your machine have more memory than my, try to enlarge MAX_NO & MAX_TIME to increase the probability of error.
Comment 3 Julian Seward 2008-11-06 11:12:36 UTC
You say "this is result running by valgrind:" (requires VIRT=1770M)
and "this is result running without valgrind:" (VIRT=72752).  This
is a ratio of 1770/72.7 = 24.3:1.  I cannot reproduce this -- I see
a ratio more like 5:1.  Can you check your measurements are correct?
I can only fix this problem if I can reproduce it.
Comment 4 Nicholas Nethercote 2009-06-26 03:34:36 UTC
Fisher, please reopen if you still see the problem and you can provide more information.
Comment 5 Andrew Crouthamel 2018-09-19 04:38:24 UTC
Dear Bug Submitter,

This bug has been in NEEDSINFO status with no change for at least 15 days. Please provide the requested information as soon as possible and set the bug status as REPORTED. Due to regular bug tracker maintenance, if the bug is still in NEEDSINFO status with no change in 30 days the bug will be closed as RESOLVED > WORKSFORME due to lack of needed information.

For more information about our bug triaging procedures please read the wiki located here: https://community.kde.org/Guidelines_and_HOWTOs/Bug_triaging

If you have already provided the requested information, please mark the bug as REPORTED so that the KDE team knows that the bug is ready to be confirmed.

Thank you for helping us make KDE software even better for everyone!
Comment 6 Bug Janitor Service 2018-11-12 16:03:44 UTC
This bug has been in NEEDSINFO status with no change for at least
30 days. The bug is now closed as RESOLVED > WORKSFORME
due to lack of needed information.

For more information about our bug triaging procedures please read the
wiki located here:
https://community.kde.org/Guidelines_and_HOWTOs/Bug_triaging

Thank you for helping us make KDE software even better for everyone!