Consider the following piece of code:
#include
#include
int main () {
char *str;
/* Initial memory allocation */
str = (char *) malloc(15);
strcpy(str, "tutorialspoint");
printf("String = %s, Address = %u\n", str, str);
str = NULL;
free(str);
return(0);
}
Why does the above program cause a memory leak? How do I avoid this?
An error is thought to occur in "str = NULL;". Why?
valgrind log:
==4143== Memcheck, a memory error detector
==4143== Copyright (C) 2002-2017, and GNU GPL'd, by Julian Seward et al.
==4143== Using Valgrind-3.13.0 and LibVEX; rerun with -h for copyright info
==4143== Command: ./a.out
==4143==
String = tutorialspoint, Address = 86097984
==4143==
==4143== HEAP SUMMARY:
==4143== in use at exit: 15 bytes in 1 blocks
==4143== total heap usage: 2 allocs, 1 frees, 1,039 bytes allocated
==4143==
==4143== 15 bytes in 1 blocks are definitely lost in loss record 1 of 1
==4143== at 0x4C2FB0F: malloc (in /usr/lib/valgrind/vgpreload_memcheck-amd64-linux.so)
==4143== by 0x1086EB: main (in /home/stack/a.out)
==4143==
==4143== LEAK SUMMARY:
==4143== definitely lost: 15 bytes in 1 blocks
==4143== indirectly lost: 0 bytes in 0 blocks
==4143== possibly lost: 0 bytes in 0 blocks
==4143== still reachable: 0 bytes in 0 blocks
==4143== suppressed: 0 bytes in 0 blocks
==4143==
==4143== For counts of detected and suppressed errors, rerun with: -v
==4143== ERROR SUMMARY: 1 errors from 1 contexts (suppressed: 0 from 0)
free(str); frees the space pointed to by str, where str is the space obtained by malloc. Because of the line str = NULL; happens before the free, free is attempting to deallocate the memory position at location 0. By definition in the C standard, this does nothing. It is common to set a pointer to 0 after it is deleted, so that if one were to accidentally attempt to delete it again, nothing happens.
To fix you code, you simply need to swap the lines str = NULL; and free(str);
Related
We are doing some performance measurements including some memory footprint measurements. We've been doing this with GNU time.
But, I cannot tell if they are measuring in kilobytes (1000 bytes) or kibibytes (1024 bytes).
The man page for my system says of the %M format key (which we are using to measure peak memory usage): "Maximum resident set size of the process during its lifetime, in Kbytes."
I assume K here means the SI "Kilo" prefix, and thus kilobytes.
But having looked at a few other memory measurements of various things through various tools, I trust that assumption like I'd trust a starved lion to watch my dogs during a week-long vacation.
I need to know, because for our tests 1000 vs 1024 Kbytes adds up to a difference of nearly 8 gigabytes, and I'd like to think I can cut down the potential error in our measurements by a few billion.
Using the below testing setup, I have determined that GNU time on my system measures in Kibibytes.
The below program (allocator.c) allocates data and touches each of it 1 KiB at a time to ensure that it all gets paged in. Note: This test only works if you can page in the entirety of the allocated data, otherwise time's measurement will only be the largest resident collection of memory.
allocator.c:
#include <stdio.h>
#include <stdlib.h>
#include <string.h>
#define min(a,b) ( ( (a)>(b) )? (b) : (a) )
volatile char access;
volatile char* data;
const int step = 128;
int main(int argc, char** argv ){
unsigned long k = strtoul( argv[1], NULL, 10 );
if( k >= 0 ){
printf( "Allocating %lu (%s) bytes\n", k, argv[1] );
data = (char*) malloc( k );
for( int i = 0; i < k; i += step ){
data[min(i,k-1)] = (char) i;
}
free( data );
} else {
printf("Bad size: %s => %lu\n", argv[1], k );
}
return 0;
}
compile with: gcc -O3 allocator.c -o allocator
Runner Bash Script:
kibibyte=1024
kilobyte=1000
mebibyte=$(expr 1024 \* ${kibibyte})
megabyte=$(expr 1000 \* ${kilobyte})
gibibyte=$(expr 1024 \* ${mebibyte})
gigabyte=$(expr 1000 \* ${megabyte})
for mult in $(seq 1 3);
do
bytes=$(expr ${gibibyte} \* ${mult} )
echo ${mult} GiB \(${bytes} bytes\)
echo "... in kibibytes: $(expr ${bytes} / ${kibibyte})"
echo "... in kilobytes: $(expr ${bytes} / ${kilobyte})"
/usr/bin/time -v ./allocator ${bytes}
echo "===================================================="
done
For me this produces the following output:
1 GiB (1073741824 bytes)
... in kibibytes: 1048576
... in kilobytes: 1073741
Allocating 1073741824 (1073741824) bytes
Command being timed: "./a.out 1073741824"
User time (seconds): 0.12
System time (seconds): 0.52
Percent of CPU this job got: 75%
Elapsed (wall clock) time (h:mm:ss or m:ss): 0:00.86
Average shared text size (kbytes): 0
Average unshared data size (kbytes): 0
Average stack size (kbytes): 0
Average total size (kbytes): 0
Maximum resident set size (kbytes): 1049068
Average resident set size (kbytes): 0
Major (requiring I/O) page faults: 0
Minor (reclaiming a frame) page faults: 262309
Voluntary context switches: 7
Involuntary context switches: 2
Swaps: 0
File system inputs: 16
File system outputs: 8
Socket messages sent: 0
Socket messages received: 0
Signals delivered: 0
Page size (bytes): 4096
Exit status: 0
====================================================
2 GiB (2147483648 bytes)
... in kibibytes: 2097152
... in kilobytes: 2147483
Allocating 2147483648 (2147483648) bytes
Command being timed: "./a.out 2147483648"
User time (seconds): 0.21
System time (seconds): 1.09
Percent of CPU this job got: 99%
Elapsed (wall clock) time (h:mm:ss or m:ss): 0:01.31
Average shared text size (kbytes): 0
Average unshared data size (kbytes): 0
Average stack size (kbytes): 0
Average total size (kbytes): 0
Maximum resident set size (kbytes): 2097644
Average resident set size (kbytes): 0
Major (requiring I/O) page faults: 0
Minor (reclaiming a frame) page faults: 524453
Voluntary context switches: 4
Involuntary context switches: 3
Swaps: 0
File system inputs: 0
File system outputs: 8
Socket messages sent: 0
Socket messages received: 0
Signals delivered: 0
Page size (bytes): 4096
Exit status: 0
====================================================
3 GiB (3221225472 bytes)
... in kibibytes: 3145728
... in kilobytes: 3221225
Allocating 3221225472 (3221225472) bytes
Command being timed: "./a.out 3221225472"
User time (seconds): 0.38
System time (seconds): 1.60
Percent of CPU this job got: 99%
Elapsed (wall clock) time (h:mm:ss or m:ss): 0:01.98
Average shared text size (kbytes): 0
Average unshared data size (kbytes): 0
Average stack size (kbytes): 0
Average total size (kbytes): 0
Maximum resident set size (kbytes): 3146220
Average resident set size (kbytes): 0
Major (requiring I/O) page faults: 0
Minor (reclaiming a frame) page faults: 786597
Voluntary context switches: 4
Involuntary context switches: 3
Swaps: 0
File system inputs: 0
File system outputs: 8
Socket messages sent: 0
Socket messages received: 0
Signals delivered: 0
Page size (bytes): 4096
Exit status: 0
====================================================
In the "Maximum resident set size" entry, I see values that are closest to the kibibytes value I expect from that raw byte count. There is some difference because its possible that some memory is being paged out (in cases where it is lower, which none of them are here) and because there is more memory being consumed than what the program allocates (namely, the stack and the actual binary image itself).
Versions on my system:
> gcc --version
gcc (GCC) 6.1.0
Copyright (C) 2016 Free Software Foundation, Inc.
This is free software; see the source for copying conditions. There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.
> /usr/bin/time --version
GNU time 1.7
> lsb_release -a
LSB Version: :base-4.0-amd64:base-4.0-noarch:core-4.0-amd64:core-4.0-noarch:graphics-4.0-amd64:graphics-4.0-noarch:printing-4.0-amd64:printing-4.0-noarch
Distributor ID: CentOS
Description: CentOS release 6.10 (Final)
Release: 6.10
Codename: Final
I want to dump the memory pages of a process once it finishes execution. I'm trying to use gdb for that, First I set break points at exit and _exit then I run the process inside gdb, once the process breaks I use info proc mappings to get the memory map of the process. it looks like the following:
Mapped address spaces:
Start Addr End Addr Size Offset objfile
0x400000 0x415000 0x15000 0x0 /path/workspace/freqmine
0x614000 0x615000 0x1000 0x14000 /path/workspace/freqmine
0x615000 0x616000 0x1000 0x15000 /path/workspace/freqmine
0x616000 0x129b000 0xc85000 0x0 [heap]
0x7ffff71f4000 0x7ffff720a000 0x16000 0x0 /lib/x86_64-linux-gnu/libgcc_s.so.1
0x7ffff720a000 0x7ffff7409000 0x1ff000 0x16000 /lib/x86_64-linux-gnu/libgcc_s.so.1
0x7ffff7409000 0x7ffff740a000 0x1000 0x15000 /lib/x86_64-linux-gnu/libgcc_s.so.1
0x7ffff740a000 0x7ffff750f000 0x105000 0x0 /lib/x86_64-linux-gnu/libm-2.19.so
0x7ffff750f000 0x7ffff770e000 0x1ff000 0x105000 /lib/x86_64-linux-gnu/libm-2.19.so
0x7ffff770e000 0x7ffff770f000 0x1000 0x104000 /lib/x86_64-linux-gnu/libm-2.19.so
0x7ffff770f000 0x7ffff7710000 0x1000 0x105000 /lib/x86_64-linux-gnu/libm-2.19.so
0x7ffff7710000 0x7ffff78cb000 0x1bb000 0x0 /lib/x86_64-linux-gnu/libc-2.19.so
0x7ffff78cb000 0x7ffff7acb000 0x200000 0x1bb000 /lib/x86_64-linux-gnu/libc-2.19.so
0x7ffff7acb000 0x7ffff7acf000 0x4000 0x1bb000 /lib/x86_64-linux-gnu/libc-2.19.so
0x7ffff7acf000 0x7ffff7ad1000 0x2000 0x1bf000 /lib/x86_64-linux-gnu/libc-2.19.so
0x7ffff7ad1000 0x7ffff7ad6000 0x5000 0x0
0x7ffff7ad6000 0x7ffff7bbc000 0xe6000 0x0 /usr/lib/x86_64-linux-gnu/libstdc++.so.6.0.19
0x7ffff7bbc000 0x7ffff7dbb000 0x1ff000 0xe6000 /usr/lib/x86_64-linux-gnu/libstdc++.so.6.0.19
0x7ffff7dbb000 0x7ffff7dc3000 0x8000 0xe5000 /usr/lib/x86_64-linux-gnu/libstdc++.so.6.0.19
0x7ffff7dc3000 0x7ffff7dc5000 0x2000 0xed000 /usr/lib/x86_64-linux-gnu/libstdc++.so.6.0.19
0x7ffff7dc5000 0x7ffff7dda000 0x15000 0x0
0x7ffff7dda000 0x7ffff7dfd000 0x23000 0x0 /lib/x86_64-linux-gnu/ld-2.19.so
0x7ffff7fce000 0x7ffff7fd3000 0x5000 0x0
0x7ffff7ff7000 0x7ffff7ffa000 0x3000 0x0
0x7ffff7ffa000 0x7ffff7ffc000 0x2000 0x0 [vdso]
0x7ffff7ffc000 0x7ffff7ffd000 0x1000 0x22000 /lib/x86_64-linux-gnu/ld-2.19.so
0x7ffff7ffd000 0x7ffff7ffe000 0x1000 0x23000 /lib/x86_64-linux-gnu/ld-2.19.so
0x7ffff7ffe000 0x7ffff7fff000 0x1000 0x0
0x7ffffffdd000 0x7ffffffff000 0x22000 0x0 [stack]
0xffffffffff600000 0xffffffffff601000 0x1000 0x0 [vsyscall]
Now I have two questions, first: getconf PAGESIZE on my machine returns 4096 which is equal to 0x1000, some of these memory spaces have different sizes though. how is that possible? are these spaces memory pages or just logical spaces? if these are not memory pages, how can I view the addresses of memory pages, or even directly dump memory pages to files?
my second question is the following: these addresses are supposed to be virtual addresses viewed by the program (not physical addresses), so why doesn't the program space start at 0? if I try to dump the memory starting from address 0 I get the following error: Cannot access memory at address 0x0. also why are there some regions in between these memory spaces that cannot be accessed (the region after the heap for example)? shouldn't the virtual space of a process be contiguous?
some of these memory spaces have different sizes though. how is that possible?
Easy: they span multiple pages (note that all of their sizes are multiples of 0x1000).
are these spaces memory pages or just logical spaces?
They are spans of one or more pages that have the same underlying mapping (the same file) and the same protections. I am not sure what exactly you call "logical spaces", but chances are you can call them that.
these addresses are supposed to be virtual addresses viewed by the program (not physical addresses),
Correct.
so why doesn't the program space start at 0?
Because long time ago VAX machines used to map something at address 0, and that made finding NULL pointer dereferences hard (they didn't crash). This was decided to be a bad idea, so later UNIX variants do not map zero page, and any attempt to dereference a NULL pointer causes SIGSEGV, helping you to debug your programs.
I have a global variable cv::Mat imageInputRGBA which I want to release it at the end of my program in a clean up function. But I receive a memory leakage message like below from Valgrind. Could anyone please give me any advice how can I can free the the Mat memory correctly without memory leakage?:
==4499== Memcheck, a memory error detector
==4499== Copyright (C) 2002-2013, and GNU GPL'd, by Julian Seward et al.
==4499== Using Valgrind-3.10.0.SVN and LibVEX; rerun with -h for copyright info
==4499== Command: ./nwcc7 im2.png im6.png
==4499==
==4499==
==4499== HEAP SUMMARY:
==4499== in use at exit: 6,086 bytes in 3 blocks
==4499== total heap usage: 412 allocs, 409 frees, 25,693,438 bytes allocated
==4499==
==4499== 30 bytes in 1 blocks are still reachable in loss record 1 of 3
==4499== at 0x4C2AB80: malloc (in /usr/lib/valgrind/vgpreload_memcheck-amd64-linux.so)
==4499== by 0x5D64679: strdup (strdup.c:42)
==4499== by 0x698D59E: ??? (in /usr/lib/nvidia-331-updates/libGL.so.331.38)
==4499== by 0x6578652F3938: ???
==4499==
==4499== 32 bytes in 1 blocks are still reachable in loss record 2 of 3
==4499== at 0x4C2CC70: calloc (in /usr/lib/valgrind/vgpreload_memcheck-amd64-linux.so)
==4499== by 0x60A268F: _dlerror_run (dlerror.c:141)
==4499== by 0x60A2197: dlsym (dlsym.c:70)
==4499== by 0x698B8BD: ??? (in /usr/lib/nvidia-331-updates/libGL.so.331.38)
==4499== by 0x6BCD5BF: ??? (in /usr/lib/nvidia-331-updates/libGL.so.331.38)
==4499== by 0x6C00A5F: ???
==4499== by 0x69B12CA: ??? (in /usr/lib/nvidia-331-updates/libGL.so.331.38)
==4499==
==4499== 6,024 bytes in 1 blocks are definitely lost in loss record 3 of 3
==4499== at 0x4C2CC70: calloc (in /usr/lib/valgrind/vgpreload_memcheck-amd64-linux.so)
==4499== by 0x69A427E: ??? (in /usr/lib/nvidia-331-updates/libGL.so.331.38)
==4499==
==4499== LEAK SUMMARY:
==4499== definitely lost: 6,024 bytes in 1 blocks
==4499== indirectly lost: 0 bytes in 0 blocks
==4499== possibly lost: 0 bytes in 0 blocks
==4499== still reachable: 62 bytes in 2 blocks
==4499== suppressed: 0 bytes in 0 blocks
==4499==
==4499== For counts of detected and suppressed errors, rerun with: -v
==4499== ERROR SUMMARY: 1 errors from 1 contexts (suppressed: 0 from 0)
//--------------------------------------
The code is something like this:
cv::Mat imageInputRGBA;
void CPU_cleanUp(){
imageInputRGBA.release();
}
int main(int argc, char **argv) {
CPU_Part(argc,argv);// I didn't use imageInputRGBA in CPU_Part
CPU_cleanUp();
return 0;
}
I build an iPad application and profile it with XCode, I got memory leaks in Security framework, following is some of them from Instruments:
Leaked Object # Address Size Responsible Library Responsible Frame
Malloc 128 Bytes,4 < multiple > 512 Bytes Security mp_init
Malloc 128 Bytes, 0x824aa70 128 Bytes Security mp_init
Malloc 128 Bytes, 0x824a9f0 128 Bytes Security mp_init
Malloc 128 Bytes, 0x824a970 128 Bytes Security mp_init
Malloc 128 Bytes, 0x824a8f0 128 Bytes Security mp_init
Leaked Object # Address Size Responsible Library Responsible Frame
Malloc 16 Bytes,4 < multiple > 64 Bytes Security init
Malloc 16 Bytes, 0x824a550 16 Bytes Security init
Malloc 16 Bytes, 0x824a540 16 Bytes Security init
Malloc 16 Bytes, 0x82493d0 16 Bytes Security init
Malloc 16 Bytes, 0x8237ca0 16 Bytes Security init
and some of the details:
# Category Event Type Timestamp RefCt Address Size Responsible Library Responsible Caller
0 Malloc 128 Bytes Malloc 00:02.240.888 1 0x824aa70 128 Security mp_init
# Category Event Type Timestamp RefCt Address Size Responsible Library Responsible Caller
0 Malloc 16 Bytes Malloc 00:02.240.886 1 0x824a550 16 Security init
I use ASIHTTP, FMDatabase and some other frameworks(I do not think they will cause the problem) in my application, and no Security framework in "Link Binary With Libraries", so I have no idea what's going wrong.
Can anyone figure out what may cause the leaks?
I have written a code in OpenGL-ES 2.0 with PVRSDK in Ubuntu 10.10 , now the thing is that whatever output I want , I am getting that but it comes and then the window disappears ,
If I put a break-point I am getting what I want. But I don't understand why the window disappears .
When I do the memory check with valgrind I got these errors :
==5997== Memcheck, a memory error detector
==5997== Copyright (C) 2002-2010, and GNU GPL'd, by Julian Seward et al.
==5997== Using Valgrind-3.6.0.SVN-Debian and LibVEX; rerun with -h for copyright info
==5997== Command: ./cube
==5997==
libEGL warning: use software fallback
==5997==
==5997== HEAP SUMMARY:
==5997== in use at exit: 12,126 bytes in 94 blocks
==5997== total heap usage: 97,499 allocs, 97,405 frees, 197,353,970 bytes allocated
==5997==
==5997== 8 bytes in 1 blocks are definitely lost in loss record 3 of 57
==5997== at 0x4024F12: calloc (vg_replace_malloc.c:467)
==5997== by 0x486CE90: __glXInitialize (glxinit.c:584)
==5997== by 0x486AA61: x11_screen_support (x11_screen.c:133)
==5997== by 0x486DEEB: x11_create_dri2_display (native_dri2.c:700)
==5997== by 0x4869AEA: native_create_display (native_x11.c:42)
==5997== by 0x4866A2A: egl_g3d_initialize (egl_g3d.c:498)
==5997== by 0x4176F36: _eglMatchDriver (egldriver.c:580)
==5997== by 0x4170BBF: eglInitialize (eglapi.c:294)
==5997== by 0x8049EFF: main (Hello.cpp:231)
==5997==
==5997== 40 bytes in 1 blocks are definitely lost in loss record 31 of 57
==5997== at 0x4026351: operator new(unsigned int) (vg_replace_malloc.c:255)
==5997== by 0x8049CE3: main (Hello.cpp:206)
==5997==
==5997== 72 bytes in 1 blocks are definitely lost in loss record 34 of 57
==5997== at 0x4024F12: calloc (vg_replace_malloc.c:467)
==5997== by 0x4A50C7C: st_bufferobj_alloc (st_cb_bufferobjects.c:56)
==5997== by 0x49A1B78: _mesa_alloc_shared_state (shared.c:94)
==5997== by 0x498860F: _mesa_initialize_context_for_api (context.c:904)
==5997== by 0x49886DB: _mesa_create_context_for_api (context.c:1050)
==5997== by 0x49C7479: st_create_context (st_context.c:176)
==5997== by 0x4985A80: st_api_create_context (st_manager.c:646)
==5997== by 0x4868843: egl_g3d_create_context (egl_g3d_api.c:131)
==5997== by 0x4173127: eglCreateContext (eglapi.c:413)
==5997== by 0x804A039: main (Hello.cpp:261)
==5997==
==5997== 1,546 (48 direct, 1,498 indirect) bytes in 1 blocks are definitely lost in loss record 55 of 57
==5997== at 0x4025BD3: malloc (vg_replace_malloc.c:236)
==5997== by 0x4BABD13: talloc_enable_null_tracking (in /usr/lib/libtalloc.so.2.0.1)
==5997== by 0x4BABE28: talloc_init (in /usr/lib/libtalloc.so.2.0.1)
==5997== by 0x49F48B5: glsl_symbol_table::glsl_symbol_table() (glsl_symbol_table.cpp:60)
==5997== by 0x49F2566: _mesa_glsl_parse_state::_mesa_glsl_parse_state(__GLcontextRec*, unsigned int, void*) (glsl_parser_extras.cpp:50)
==5997== by 0x49D68B3: _mesa_glsl_compile_shader (ir_to_mesa.cpp:2815)
==5997== by 0x49A0486: _mesa_CompileShaderARB (shaderapi.c:807)
==5997== by 0x804A0E1: main (Hello.cpp:280)
==5997==
==5997== LEAK SUMMARY:
==5997== definitely lost: 168 bytes in 4 blocks
==5997== indirectly lost: 1,498 bytes in 28 blocks
==5997== possibly lost: 0 bytes in 0 blocks
==5997== still reachable: 10,460 bytes in 62 blocks
==5997== suppressed: 0 bytes in 0 blocks
==5997== Reachable blocks (those to which a pointer was found) are not shown.
==5997== To see them, rerun with: --leak-check=full --show-reachable=yes
==5997==
==5997== For counts of detected and suppressed errors, rerun with: -v
==5997== ERROR SUMMARY: 4 errors from 4 contexts (suppressed: 54 from 11)
Now those lines which they are mentioning :
206 x11Visual = new XVisualInfo;
207 XMatchVisualInfo( x11Display, x11Screen, i32Depth, TrueColor, x11Vis ual);
208 if (!x11Visual)
209 {
210 printf("Error: Unable to acquire visual\n");
211 goto cleanup;
212 }
===========================================================================================
230 EGLint iMajorVersion, iMinorVersion;
231 if (!eglInitialize(eglDisplay, &iMajorVersion, &iMinorVersion))
232 {
233 printf("Error: eglInitialize() failed.\n");
234 }
==========================================================================================
eglContext = eglCreateContext(eglDisplay, eglConfig, NULL, ai32Conte xtAttribs);
262 if (!TestEGLError("eglCreateContext"))
263 {
264 goto cleanup;
265 }
============================================================================================
279 glShaderSource(uiFragShader, 1, (const char**)&pszFragShader, NULL);
280 glCompileShader(uiFragShader);
So I just want to know that its because of these errors I am getting that screen disappears or something else might be the reason .
I just want to know that its because of these errors I am getting that screen disappears or something else might be the reason
The latter. Leaks do not affect program runtime (unless they are so large that the program fails to allocate more memory when it needs it; but your leaks are small).
Did you forget to enter the X event loop?
Update:
int i32NumMessages = XPending( x11Display );
for( int i = 0; i < i32NumMessages; i++ )
{
XEvent event;
XNextEvent( x11Display, &event );
}
That loop is in fact
obviously wrong
the reason your application (almost) immediately exits
You are processing only the events queued so far (which is likely a very small number of events). And you are actually discarding them. You'll probably want to write something like this instead.