Context
I want to use Intel's MKL library to create an array and then do various stuff with it. However, it segfaults on mkl_malloc.
Problem
I am trying to run the following program. On running it, I get a segfault at the specified line. The problem is with mkl_malloc. What can I do to fix this? What is going on?
#include "mkl_types.h"
#include "mkl_spblas.h"
#include <stddef.h> // For NULL
#include <stdio.h>
// Find reason for segfault
int main() {
MKL_INT m=2000, k=1000;
double *A_dense;
// Allocate memory to matrix
A_dense = (double *)mkl_malloc( m*k*sizeof( double ), 128); // Fails here.
if (A_dense == NULL) {
printf("ERROR: Can't allocate memory for matrices. Aborting... \n\n");
mkl_free(A_dense);
return 1;
}
mkl_free(A_dense);
return 0;
}
Compile with:
$ export LD_LIBRARY_PATH=$LD_LIBRARY_PATH:/opt/intel/mkl/lib/intel65
$ gcc -m64 -I/opt/intel/mkl/include -L/opt/intel/mkl/lib/intel64 -lmkl_rt -lpthread -lm test_alloc.c -o test
test
test_alloc.c: In function 'main':
test_alloc.c:13:15: warning: cast to pointer from integer of different size [-Wint-to-pointer-cast]
The output I get with valgrind is thus:
$ valgrind --leak-check=full ./test
==69680== Memcheck, a memory error detector
==69680== Copyright (C) 2002-2011, and GNU GPL'd, by Julian Seward et al.
==69680== Using Valgrind-3.7.0 and LibVEX; rerun with -h for copyright info
==69680== Command: ./test
==69680==
==69680== Invalid read of size 8
==69680== at 0x868D1D1: MKL_MALLOC (in /opt/intel/composerxe-2011.5.220/mkl/lib/intel64/libmkl_intel_lp64.so)
==69680== by 0x4F56B1C: MKL_MALLOC (in /opt/intel/composerxe-2011.5.220/mkl/lib/intel64/libmkl_rt.so)
==69680== by 0x4006B0: main (in /export/home/myuser/devel/part_distances/lib/test)
==69680== Address 0xf42400 is not stack'd, malloc'd or (recently) free'd
==69680==
==69680==
==69680== Process terminating with default action of signal 11 (SIGSEGV)
==69680== Access not within mapped region at address 0xF42400
==69680== at 0x868D1D1: MKL_MALLOC (in /opt/intel/composerxe-2011.5.220/mkl/lib/intel64/libmkl_intel_lp64.so)
==69680== by 0x4F56B1C: MKL_MALLOC (in /opt/intel/composerxe-2011.5.220/mkl/lib/intel64/libmkl_rt.so)
==69680== by 0x4006B0: main (in /export/home/myuser/devel/part_distances/lib/test)
==69680== If you believe this happened as a result of a stack
==69680== overflow in your program's main thread (unlikely but
==69680== possible), you can try to increase the size of the
==69680== main thread stack using the --main-stacksize= flag.
==69680== The main thread stack size used in this run was 8388608.
==69680==
==69680== HEAP SUMMARY:
==69680== in use at exit: 4,603 bytes in 19 blocks
==69680== total heap usage: 19 allocs, 0 frees, 4,603 bytes allocated
==69680==
==69680== LEAK SUMMARY:
==69680== definitely lost: 0 bytes in 0 blocks
==69680== indirectly lost: 0 bytes in 0 blocks
==69680== possibly lost: 0 bytes in 0 blocks
==69680== still reachable: 4,603 bytes in 19 blocks
==69680== suppressed: 0 bytes in 0 blocks
==69680== Reachable blocks (those to which a pointer was found) are not shown.
==69680== To see them, rerun with: --leak-check=full --show-reachable=yes
==69680==
==69680== For counts of detected and suppressed errors, rerun with: -v
==69680== ERROR SUMMARY: 1 errors from 1 contexts (suppressed: 4 from 4)
Segmentation fault
Alternatives
I am using Single Dynamic Linking (SDL) because I can't get static linking to work.
The documentation suggests including mkl.h.
So change:
#include "mkl_types.h"
#include "mkl_spblas.h"
to
#include "mkl.h"
You get a scary warning:
test_alloc.c:13:15: warning: cast to pointer from integer of different size [-Wint-to-pointer-cast]
I assume this is from the code line that does the call to mkl_malloc():
A_dense = (double *)mkl_malloc( m*k*sizeof( double ), 128);
This implies that you're missing the header, since otherwise there would be no "integer" here.
Also, you should never cast a void * like that in C, as I might have mentioned before on this site.
Related
For the past 2 hours or so, I have been trying to figure out why the following code throws a "possibly lost" memory leak:
#include <stdio.h>
#include <stdlib.h>
#include <pthread.h>
#include <readline/readline.h>
#include <readline/history.h>
void *my_read(void* arg) {
char* buf;
if ((buf = readline(">> ")) != NULL) {
printf("Test\n");
if (strlen(buf) > 0) {
add_history(buf);
}
free(buf);
}
pthread_exit(0);
}
int main(int argc, char** argv) {
rl_catch_signals = 0;
pthread_t thread;
pthread_create(&thread, NULL, my_read, NULL);
pthread_join(thread, NULL);
return 0;
}
And I have also tried using detach instead of join, but the result is the same, which is:
==1498903== 272 bytes in 1 blocks are possibly lost in loss record 31 of 78
==1498903== at 0x4849C0F: calloc (vg_replace_malloc.c:1328)
==1498903== by 0x4012662: allocate_dtv (in /lib64/ld-linux-x86-64.so.2)
==1498903== by 0x401309D: _dl_allocate_tls (in /lib64/ld-linux-x86-64.so.2)
==1498903== by 0x497FAA4: pthread_create##GLIBC_2.34 (in /lib64/libc.so.6)
==1498903== by 0x10927B: main (in /home/user/readline)
I have also tried just straight up allocating memory and freeing it in a loop, which shows the same result.
EDIT: Picked the read -> my_read fix from Ajay, but the main issue still remains.
The main problem here is that you have defined a function named read. Readline internally calls the read function to read from stdin. This ends up recursively calling your read function leading to a stackoverflow and crashing your program. The crashed program doesn't free memory for the pthread_t state which should be done when you call pthread_join. This is the main reason valgrind complains.
A simple fix is to read --> my_read.
With the proposed fix the output of valgrind --leak-check=full on my end is -
==27167== Memcheck, a memory error detector
==27167== Copyright (C) 2002-2017, and GNU GPL'd, by Julian Seward et al.
==27167== Using Valgrind-3.13.0 and LibVEX; rerun with -h for copyright info
==27167== Command: ./test
==27167==
>> hello
Test
==27167==
==27167== HEAP SUMMARY:
==27167== in use at exit: 134,297 bytes in 195 blocks
==27167== total heap usage: 316 allocs, 121 frees, 155,633 bytes allocated
==27167==
==27167== LEAK SUMMARY:
==27167== definitely lost: 0 bytes in 0 blocks
==27167== indirectly lost: 0 bytes in 0 blocks
==27167== possibly lost: 0 bytes in 0 blocks
==27167== still reachable: 134,297 bytes in 195 blocks
==27167== suppressed: 0 bytes in 0 blocks
==27167== Reachable blocks (those to which a pointer was found) are not shown.
==27167== To see them, rerun with: --leak-check=full --show-leak-kinds=all
==27167==
==27167== For counts of detected and suppressed errors, rerun with: -v
==27167== ERROR SUMMARY: 0 errors from 0 contexts (suppressed: 0 from 0)
Description
This is an example created to introduce issue from larger solution. I have to use flex and yy_scan_string(). I have an issue with memory leaks in flex (code below). In this example memory leaks are marked as "still reachable", but in the original solution they get marked as "lost memory".
I think this problem is somewhere in memory allocated by flex internally, which I don't know how to free properly and I can't find any tutorial / documentation for that issue.
file.lex
%option noyywrap
%{
#include <stdio.h>
%}
%%
. printf("%s\n", yytext);
%%
int main() {
printf("Start\n");
yy_scan_string("ABC");
yylex();
printf("Stop\n");
return 0;
}
bash$ flex file.lex
bash$ gcc lex.yy.c
bash$ ./a.out
Start
H
a
l
l
o
W
o
r
l
d
Stop
bash$ valgrind --leak-check=full --show-leak-kinds=all ./a.out
==6351== Memcheck, a memory error detector
==6351== Copyright (C) 2002-2017, and GNU GPL'd, by Julian Seward et al.
==6351== Using Valgrind-3.14.0 and LibVEX; rerun with -h for copyright info
==6351== Command: ./a.out
==6351==
==6351== error calling PR_SET_PTRACER, vgdb might block
Start
A
B
C
Stop
==6351==
==6351== HEAP SUMMARY:
==6351== in use at exit: 77 bytes in 3 blocks
==6351== total heap usage: 4 allocs, 1 frees, 589 bytes allocated
==6351==
==6351== 5 bytes in 1 blocks are still reachable in loss record 1 of 3
==6351== at 0x483577F: malloc (vg_replace_malloc.c:299)
==6351== by 0x10AE84: yyalloc (in ./a.out)
==6351== by 0x10ABE5: yy_scan_bytes (in ./a.out)
==6351== by 0x10ABBC: yy_scan_string (in ./a.out)
==6351== by 0x10AEE2: main (in /home/./a.out)
==6351==
==6351== 8 bytes in 1 blocks are still reachable in loss record 2 of 3
==6351== at 0x483577F: malloc (vg_replace_malloc.c:299)
==6351== by 0x10AE84: yyalloc (in ./a.out)
==6351== by 0x10A991: yyensure_buffer_stack (in ./a.out)
==6351== by 0x10A38D: yy_switch_to_buffer (in ./a.out)
==6351== by 0x10AB8E: yy_scan_buffer (in ./a.out)
==6351== by 0x10AC68: yy_scan_bytes (in ./a.out)
==6351== by 0x10ABBC: yy_scan_string (in ./a.out)
==6351== by 0x10AEE2: main (in ./a.out)
==6351==
==6351== 64 bytes in 1 blocks are still reachable in loss record 3 of 3
==6351== at 0x483577F: malloc (vg_replace_malloc.c:299)
==6351== by 0x10AE84: yyalloc (in ./a.out)
==6351== by 0x10AAEF: yy_scan_buffer (in ./a.out)
==6351== by 0x10AC68: yy_scan_bytes (in ./a.out)
==6351== by 0x10ABBC: yy_scan_string (in ./a.out)
==6351== by 0x10AEE2: main (in ./a.out)
==6351==
==6351== LEAK SUMMARY:
==6351== definitely lost: 0 bytes in 0 blocks
==6351== indirectly lost: 0 bytes in 0 blocks
==6351== possibly lost: 0 bytes in 0 blocks
==6351== still reachable: 77 bytes in 3 blocks
==6351== suppressed: 0 bytes in 0 blocks
==6351==
==6351== For counts of detected and suppressed errors, rerun with: -v
==6351== ERROR SUMMARY: 0 errors from 0 contexts (suppressed: 0 from 0)
The answer is mentioned in the flex documentation, but you have to read carefully to find it. (See below.)
If you generate a reentrant scanner, then you are responsible for creating and destroying each scanner object you require, and the scanner object manages all of the memory required by a scanner instance. But even if you don't use the reentrant interface, you can use yylex_destroy to manage memory. In the traditional non-reentrant interface, then there is no scanner_t argument, so the prototype of yylex_destroy is simply
int yylex_destroy(void);
(Although it has a return value which is supposed to be a status code, it never returns an error.)
You can, if you want to, call yylex_init, which also takes no arguments in the non-reentrant interface, but unlike the reentrant interface, it is not necessary to call it.
From the manual chapter on memory management:
Flex allocates dynamic memory during initialization, and once in a while from within a call to yylex(). Initialization takes place during the first call to yylex(). Thereafter, flex may reallocate more memory if it needs to enlarge a buffer. As of version 2.5.9 Flex will clean up all memory when you call yylex_destroy See faq-memory-leak.
Example:
$ cat clean.l
%option noinput nounput noyywrap nodefault
%{
#include <stdio.h>
%}
%%
.|\n ECHO;
%%
int main() {
printf("Start\n");
yy_scan_string("ABC");
yylex();
printf("Stop\n");
yylex_destroy();
return 0;
}
$ flex -o clean.c clean.l
$ gcc -Wall -o clean clean.c
$ valgrind --leak-check=full --show-leak-kinds=all ./clean
==16187== Memcheck, a memory error detector
==16187== Copyright (C) 2002-2017, and GNU GPL'd, by Julian Seward et al.
==16187== Using Valgrind-3.13.0 and LibVEX; rerun with -h for copyright info
==16187== Command: ./clean
==16187==
Start
ABCStop
==16187==
==16187== HEAP SUMMARY:
==16187== in use at exit: 0 bytes in 0 blocks
==16187== total heap usage: 4 allocs, 4 frees, 1,101 bytes allocated
==16187==
==16187== All heap blocks were freed -- no leaks are possible
==16187==
==16187== For counts of detected and suppressed errors, rerun with: -v
==16187== ERROR SUMMARY: 0 errors from 0 contexts (suppressed: 0 from 0)
I am trying to implement the function int *cpy_array(int v[], int size), which copies the array in another and returns the new array as pointer. I also have to watch out for error cases and use dynamic memory.
Ok i know that malloc returns 0 when there is nout enough memory available. I was wondering if there might be any other possible errors as well which I missed out. Then I have to implement free() in the case of succsess as well as in error case.
I tried to implement something like:
if (!w[i]) {
for (k = 0; k < i; ++k)
free(w[k]);
return 0;
}
But there was always an error with this.
In file included from hot.c:2:
C:/mingw-w64/i686-8.1.0-posix-dwarf-rt_v6-rev0/mingw32/i686-w64-mingw32/include/stdlib.h:502:27: note: expected 'void *' but argument is of type 'int'"
void __cdecl free(void *_Memory);
And I am not sure why to free() the new array or should the old array be freed? I tried to free it with pointer in my function, but didnt work either and dont think it should be in the main?
Here is the original code:
int *cpy_array(int v[], int size);
int main(void)
{
int size;
size = 4;
int myArray[4] = {1234};
if (*cpy_array(myArray, size) == 0)
{
printf("No memory available.");
}else{
printf("The new Array: %i", *cpy_array(myArray, size));
}
return 0;
}
int *cpy_array(int v[], int size)
{
int i;
int *a = malloc(size * sizeof(int));
if(*a == 0)
return 0;
for (i = 0; i < size; i++)
{
a[i] = v[i];
}
return a;
}
In your first code snippet, you incorrectly deallocated the array of integers w. You can't free single integers in that array, but what you need to do is simply type in:
free(w);
That will free the entire array.
You can also see from the text of the error - note: expected 'void *' but argument is of type 'int'" void __cdecl free(void *_Memory), that the program expected a pointer to the array and not an integer.
You can't free the old array, because it's statically created and the memory for it allocated at the start of the program and it will be freed at the end of the function in which it was defined by the program itself, so you don't need to worry about that. Whereas it's your job to free the dynamically created arrays such as the one you created through the cpy_array(int v[], int size) function.
More on the difference between static and dynamic allocation, you can look up here:
Difference between static memory allocation and dynamic memory allocation
This part of code, wouldn't proparly print the array (you will just print the first number of the array), and also you are calling the function twice, which is excessive and should be done only once for the same array.
if (*cpy_array(myArray, size) == 0)
{
printf("No memory available.");
}else{
printf("The new Array: %i", *cpy_array(myArray, size));
}
You could easify fix these problems by defining a pointer which could store the return value of the function, so you don't have to call it twice and then to correctly print the array use a for loop:
int * copiedArray = cpy_array(myArray, size);
if (copiedArray == NULL)
{
printf("No memory available.");
}else{
printf("The new Array: ");
for (int i = 0; i < size; i++)
printf("%i ", copiedArray[i]);
}
I noticed that you are checking whether a pointer is pointing to something or not incorrectly. Once in main:
if (*cpy_array(myArray, size) == 0)
And once in the cpy_array(int v[], int size) function:
if(*a == 0)
This will not work because you are dereferencing the pointer and checking whether the value to which it is pointing is zero. What you want to do is check the value of the pointer itself. If that is NULL then the allocation didn't work:
if (cpy_array(myArray, size) == NULL)
and
if(a == NULL)
You should use NULL instead of zero because you are explicitly stating that you are checking a value of a pointer, and NULL may not be equal to zero on every machine.
More on that topic here:
What is the difference between NULL, '\0' and 0
To detect you problems concerning the memory use valgrind, If I do that gives :
==10947== Memcheck, a memory error detector
==10947== Copyright (C) 2002-2017, and GNU GPL'd, by Julian Seward et al.
==10947== Using Valgrind-3.13.0 and LibVEX; rerun with -h for copyright info
==10947== Command: ./a.out
==10947==
==10947== Conditional jump or move depends on uninitialised value(s)
==10947== at 0x10548: cpy_array (c.c:25)
==10947== by 0x104B3: main (c.c:11)
==10947==
==10947== Invalid read of size 4
==10947== at 0x104B8: main (c.c:11)
==10947== Address 0x0 is not stack'd, malloc'd or (recently) free'd
==10947==
==10947==
==10947== Process terminating with default action of signal 11 (SIGSEGV)
==10947== Access not within mapped region at address 0x0
==10947== at 0x104B8: main (c.c:11)
==10947== If you believe this happened as a result of a stack
==10947== overflow in your program's main thread (unlikely but
==10947== possible), you can try to increase the size of the
==10947== main thread stack using the --main-stacksize= flag.
==10947== The main thread stack size used in this run was 8388608.
==10947==
==10947== HEAP SUMMARY:
==10947== in use at exit: 16 bytes in 1 blocks
==10947== total heap usage: 1 allocs, 0 frees, 16 bytes allocated
==10947==
==10947== 16 bytes in 1 blocks are definitely lost in loss record 1 of 1
==10947== at 0x4847568: malloc (vg_replace_malloc.c:299)
==10947== by 0x10533: cpy_array (c.c:24)
==10947== by 0x104B3: main (c.c:11)
==10947==
==10947== LEAK SUMMARY:
==10947== definitely lost: 16 bytes in 1 blocks
==10947== indirectly lost: 0 bytes in 0 blocks
==10947== possibly lost: 0 bytes in 0 blocks
==10947== still reachable: 0 bytes in 0 blocks
==10947== suppressed: 0 bytes in 0 blocks
==10947==
==10947== For counts of detected and suppressed errors, rerun with: -v
==10947== Use --track-origins=yes to see where uninitialised values come from
==10947== ERROR SUMMARY: 3 errors from 3 contexts (suppressed: 6 from 3)
The "Conditional jump or move depends on uninitialised value(s)" comes from the *a in if(*a == 0) and "Invalid read of size 4 ..." because you dereference 0 because of the return 0;
after changing if(*a == 0) to if(a == 0) to solve the two previous problems that condition is (a priori) false and _valgrind says :
==11116== Memcheck, a memory error detector
==11116== Copyright (C) 2002-2017, and GNU GPL'd, by Julian Seward et al.
==11116== Using Valgrind-3.13.0 and LibVEX; rerun with -h for copyright info
==11116== Command: ./a.out
==11116==
Mein neuer Array enthaelt folgende Zeichen: 1==11116==
==11116== HEAP SUMMARY:
==11116== in use at exit: 32 bytes in 2 blocks
==11116== total heap usage: 3 allocs, 1 frees, 1,056 bytes allocated
==11116==
==11116== 16 bytes in 1 blocks are definitely lost in loss record 1 of 2
==11116== at 0x4847568: malloc (vg_replace_malloc.c:299)
==11116== by 0x10523: cpy_array (c.c:24)
==11116== by 0x104A3: main (c.c:11)
==11116==
==11116== 16 bytes in 1 blocks are definitely lost in loss record 2 of 2
==11116== at 0x4847568: malloc (vg_replace_malloc.c:299)
==11116== by 0x10523: cpy_array (c.c:24)
==11116== by 0x104CF: main (c.c:15)
==11116==
==11116== LEAK SUMMARY:
==11116== definitely lost: 32 bytes in 2 blocks
==11116== indirectly lost: 0 bytes in 0 blocks
==11116== possibly lost: 0 bytes in 0 blocks
==11116== still reachable: 0 bytes in 0 blocks
==11116== suppressed: 0 bytes in 0 blocks
==11116==
==11116== For counts of detected and suppressed errors, rerun with: -v
==11116== ERROR SUMMARY: 2 errors from 2 contexts (suppressed: 6 from 3)
so yes you have memory leaks because you lost 2 times the allocation return by cpy_array
you need to have something like :
int * v = cpy_array(myArray, size);
if (*v == 0)
{
printf("Speicher kann nicht freigegeben werden.");
}else{
printf("Mein neuer Array enthaelt folgende Zeichen: %i",
*v);
}
free(v);
Doing that correction valgrind signals nothing :
valgrind --leak-check=full ./a.out
==11224== Memcheck, a memory error detector
==11224== Copyright (C) 2002-2017, and GNU GPL'd, by Julian Seward et al.
==11224== Using Valgrind-3.13.0 and LibVEX; rerun with -h for copyright info
==11224== Command: ./a.out
==11224==
Mein neuer Array enthaelt folgende Zeichen: 1==11224==
==11224== HEAP SUMMARY:
==11224== in use at exit: 0 bytes in 0 blocks
==11224== total heap usage: 2 allocs, 2 frees, 1,040 bytes allocated
==11224==
==11224== All heap blocks were freed -- no leaks are possible
==11224==
==11224== For counts of detected and suppressed errors, rerun with: -v
==11224== ERROR SUMMARY: 0 errors from 0 contexts (suppressed: 6 from 3)
I encourage you to
compile with all warning detection, like gcc -g -Wall -pedantic ...
when you have problem use valgrind and/or debugger
even you do not see a problem run anyway under valgrind, so problems can be hidden
this is not the correct way to initialize the array
int myArray[4] = {1234};
write
int myArray[4] = { 1,2,3,4 };
or simply
int myArray[] = { 1,2,3,4 };
Calling the function cpy_array .. when you write
if (*cpy_array(myArray, size) == 0)
Is not correct, why? because what if the function returns NULL, then you are dereferencing NULL
In your function cpy_array you are dereferencing a, that is not correct, instead compare the pointer
if ( a == NULL)
and use the standard constant NULL for a null pointer instead of 0 since it may not be 0 on all platforms.
I have a simple question here. I have some variable declarations as follows:
char long_name_VARA[]="TEST -- Gridded 450m daily Evapotranspiration (ET)";
int16 fill_PET_8day=32767;
Given the above valgrind complains for the char declaration as follows:
Invalid write of size 8
==21902== at 0x408166: main (main.c:253)
==21902== Location 0x7fe677840 is 0 bytes inside long_name_VARA[0]
and for the int16 declaration as follows:
==21902== Invalid write of size 2
==21902== at 0x408178: main (main.c:226)
Location 0x7fe677420 is 0 bytes inside local var "fill_PET_8day"
What am i doing wrong in my declarations here?
Also can I not declare a char array like this:
char temp_year[5]={0}
The warning messages you quoted show invalid memory accesses, which happen to hit memory areas belonging to the above two variables. The variables in question are victims of the error, not perpetrators. The variables are not to blame here. Nothing is wrong with the above declarations. Most likely these declarations are not in any way relevant here.
The perpetrators are lines at main.c:253 and main.c:226, which you haven't quoted yet. That's where your problem occurs.
A wild guess would be that you have another object declared after fill_PET_8day (an array?). When working with that other object, you overrun its memory boundary by ~10 bytes, thus clobbering fill_PET_8day and first 8 bytes of long_name_VARA. This is what valgrind is warning you about.
As mentioned, the declarations aren't the issue.
Although FYI, it may be better to declare your constant string as const...
const char* long_name_VARA = "TEST -- Gridded 450m daily Evapotranspiration (ET)";
or even...
const char* const long_name_VARA = "TEST -- Gridded 450m daily Evapotranspiration (ET)";
This prevents the string from being modified in code, (and the pointer).
When I run the following
/* test.c */
#include <stdio.h>
int main(void)
{
char s[8000000];
int x;
s[0] = '\0';
x=5;
printf("%s %d\n",s,x);
return 0;
}
with Valgrind I get
$ gcc test.c
$ valgrind ./a.out
==1828== Memcheck, a memory error detector
==1828== Copyright (C) 2002-2013, and GNU GPL'd, by Julian Seward et al.
==1828== Using Valgrind-3.10.1 and LibVEX; rerun with -h for copyright info
==1828== Command: ./a.out
==1828==
==1828== Warning: client switching stacks? SP change: 0xfff0002e0 --> 0xffe85f0d0
==1828== to suppress, use: --max-stackframe=8000016 or greater
==1828== Invalid write of size 1
==1828== at 0x400541: main (in /home/m/a.out)
==1828== Address 0xffe85f0d0 is on thread 1's stack
==1828== in frame #0, created by main (???)
==1828==
==1828== Invalid write of size 8
==1828== at 0x400566: main (in /home/m/a.out)
==1828== Address 0xffe85f0c8 is on thread 1's stack
==1828== in frame #0, created by main (???)
==1828==
==1828== Invalid read of size 1
==1828== at 0x4E81ED3: vfprintf (vfprintf.c:1642)
==1828== by 0x4E88038: printf (printf.c:33)
==1828== by 0x40056A: main (in /home/m/a.out)
==1828== Address 0xffe85f0d0 is on thread 1's stack
==1828== in frame #2, created by main (???)
==1828==
5
==1828== Invalid read of size 8
==1828== at 0x4E88040: printf (printf.c:37)
==1828== by 0x40056A: main (in /home/m/a.out)
==1828== Address 0xffe85f0c8 is on thread 1's stack
==1828== in frame #0, created by printf (printf.c:28)
==1828==
==1828== Warning: client switching stacks? SP change: 0xffe85f0d0 --> 0xfff0002e0
==1828== to suppress, use: --max-stackframe=8000016 or greater
==1828==
==1828== HEAP SUMMARY:
==1828== in use at exit: 0 bytes in 0 blocks
==1828== total heap usage: 0 allocs, 0 frees, 0 bytes allocated
==1828==
==1828== All heap blocks were freed -- no leaks are possible
==1828==
==1828== For counts of detected and suppressed errors, rerun with: -v
==1828== ERROR SUMMARY: 4 errors from 4 contexts (suppressed: 0 from 0)
If I give the option Valgrind warns with I get
$ valgrind --max-stackframe=10000000 ./a.out
==1845== Memcheck, a memory error detector
==1845== Copyright (C) 2002-2013, and GNU GPL'd, by Julian Seward et al.
==1845== Using Valgrind-3.10.1 and LibVEX; rerun with -h for copyright info
==1845== Command: ./a.out
==1845==
5
==1845==
==1845== HEAP SUMMARY:
==1845== in use at exit: 0 bytes in 0 blocks
==1845== total heap usage: 0 allocs, 0 frees, 0 bytes allocated
==1845==
==1845== All heap blocks were freed -- no leaks are possible
==1845==
==1845== For counts of detected and suppressed errors, rerun with: -v
==1845== ERROR SUMMARY: 0 errors from 0 contexts (suppressed: 0 from 0)
So the "Invalid reads/writes" are due to the large stack variable without the proper --max-stackframe=... option.
int main(int argc, char *argv[])
{
char *ret = setlocale(LC_ALL, NULL);
// should I free 'ret' ???
// free(ret);
return 0;
}
I've tried both on Linux and OS X 10.10, on Linux, I must not call 'free', but on OS X, if I do not call 'free', valgrind complains a memory leak.
==62032== Memcheck, a memory error detector
==62032== Copyright (C) 2002-2013, and GNU GPL'd, by Julian Seward et al.
==62032== Using Valgrind-3.11.0.SVN and LibVEX; rerun with -h for copyright info
==62032== Command: ./a.out
==62032==
--62032-- ./a.out:
--62032-- dSYM directory is missing; consider using --dsymutil=yes
==62032==
==62032== HEAP SUMMARY:
==62032== in use at exit: 129,789 bytes in 436 blocks
==62032== total heap usage: 519 allocs, 83 frees, 147,421 bytes allocated
==62032==
==62032== 231 bytes in 1 blocks are definitely lost in loss record 63 of 91
==62032== at 0x10000859B: malloc (in /usr/local/Cellar/valgrind/HEAD/lib/valgrind/vgpreload_memcheck-amd64-darwin.so)
==62032== by 0x1001E68C8: currentlocale (in /usr/lib/system/libsystem_c.dylib)
==62032== by 0x100000F6B: main (in ./a.out)
==62032==
==62032== LEAK SUMMARY:
==62032== definitely lost: 231 bytes in 1 blocks
==62032== indirectly lost: 0 bytes in 0 blocks
==62032== possibly lost: 0 bytes in 0 blocks
==62032== still reachable: 94,869 bytes in 10 blocks
==62032== suppressed: 34,689 bytes in 425 blocks
==62032== Reachable blocks (those to which a pointer was found) are not shown.
==62032== To see them, rerun with: --leak-check=full --show-leak-kinds=all
==62032==
==62032== For counts of detected and suppressed errors, rerun with: -v
==62032== ERROR SUMMARY: 1 errors from 1 contexts (suppressed: 17 from 17)
So,
in Linux, if I call 'free', it will crash.
in OS X, if I do not call 'free', it has a memory leak.
You should not free the string that you get. According to the C11 standard:
7.11.1.1 The setlocale function
The pointer to string returned by the
setlocale
function is such that a subsequent call
with that string value and its associated category will restore that part of the program’s
locale. The string pointed to shall not be modified by the program, but may be
overwritten by a subsequent call to the
setlocale
function
Additionally, the Linux man pages say:
This string may be allocated in
static storage.
which would result in your program crashing if you tried to free it.
It looks like the Linux implementation uses static storage, but the OSX one uses malloc. Regardless of what's going on under the hood, you should not modify it because the standard disallows you from doing so --- the fact that it would be safe on OSX is an implementation quirk you should ignore. Valgrind is essentially giving you a false positive here.