C variable initialization valgrind complains - c

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.

Related

Flex yy_scan_string memory leaks

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)

valgrind mips doesn't show stack trace

I'm using valgrind 3.13 on mips platform, however I write a test program and found valgrind didn't trace to file line number, for x86 it works fine. what could be the problem?
# valgrind --trace-children=yes --leak-check=yes --num-callers=20 /tmp/a.out
==2957== Memcheck, a memory error detector
==2957== Copyright (C) 2002-2017, and GNU GPL'd, by Julian Seward et al.
==2957== Using Valgrind-3.13.0 and LibVEX; rerun with -h for copyright info
==2957== Command: /tmp/a.out
==2957==
==2957== Invalid write of size 4
==2957== at 0x4000B90: ??? (in /lib/ld-uClibc.so.0)
==2957== by 0x4000B3C: ??? (in /lib/ld-uClibc.so.0)
==2957== Address 0x7e8bdcbc is on thread 1's stack
==2957== 4 bytes below stack pointer
==2957==
==2957== Conditional jump or move depends on uninitialised value(s)
==2957== at 0x48B4A44: ??? (in /lib/libc.so.0)
==2957== by 0x48ADBE4: ??? (in /lib/libc.so.0)
==2957==
buf=test buf
in func1:x[10]=10
/tmp/a.out: can't resolve symbol '__libc_freeres'
==2957==
==2957== HEAP SUMMARY:
==2957== in use at exit: 0 bytes in 0 blocks
==2957== total heap usage: 0 allocs, 0 frees, 0 bytes allocated
==2957==
==2957== All heap blocks were freed -- no leaks are possible
==2957==
==2957== For counts of detected and suppressed errors, rerun with: -v
==2957== Use --track-origins=yes to see where uninitialised values come from
==2957== ERROR SUMMARY: 2 errors from 2 contexts (suppressed: 0 from 0)
Below is my test.c, compiled with mips toolchain with option "-g -O0"
#include <stdio.h>
#include <stdlib.h>
#include <string.h>
func1()
{
int *x=malloc(10*sizeof(int *));
x[10]=10;
printf("in func1:x[10]=%d\n", x[10]);
}
main()
{
char buf[2];
char buf2[10];
strcpy(buf,"test buf\n");
printf("buf=%s\n", buf);
func1();
}

malloc doesn't look to work in my program

I have a function which prints the whole content of the file and the function seems to work fine, but valgring complains about Conditional jump or move depends on uninitialised value(s) and Uninitialised value was created by a heap allocation:
==7876== Memcheck, a memory error detector
==7876== Copyright (C) 2002-2013, and GNU GPL'd, by Julian Seward et al.
==7876== Using Valgrind-3.10.1 and LibVEX; rerun with -h for copyright info
==7876== Command: ./program
==7876==
==7876== Conditional jump or move depends on uninitialised value(s)
==7876== at 0x4E864B2: vfprintf (vfprintf.c:1642)
==7876== by 0x4E8CC38: printf (printf.c:33)
==7876== by 0x40074C: main (program.c:45)
==7876== Uninitialised value was created by a heap allocation
==7876== at 0x4C2BBA0: malloc (in /usr/lib/valgrind/vgpreload_memcheck-amd64-linux.so)
==7876== by 0x4008A7: printFile (program.c:23)
==7876== by 0x40073A: main (program.c:43)
==7876==
The world is not enought and michi is the only one who's not agree.
==7876==
==7876== HEAP SUMMARY:
==7876== in use at exit: 0 bytes in 0 blocks
==7876== total heap usage: 2 allocs, 2 frees, 621 bytes allocated
==7876==
==7876== All heap blocks were freed -- no leaks are possible
==7876==
==7876== For counts of detected and suppressed errors, rerun with: -v
==7876== ERROR SUMMARY: 1 errors from 1 contexts (suppressed: 0 from 0)
Here is the program:
#include<stdio.h>
#include<string.h>
#include<stdlib.h>
char *printFile(char *fileName){
size_t length=0,size=0;
char *buffer;
FILE *file;
file = fopen (fileName , "r" );
if (file==NULL){
printf("\n");
printf("\tThe file %s does not Exists\n", fileName);
exit(1);
}
fseek (file , 0 , SEEK_END);
length = (size_t)ftell (file);
fseek (file , 0 , SEEK_SET);
buffer = malloc(length+1);
if (!buffer){
fputs ("Memory error",stderr);
exit (2);
}
size = fread (buffer,1,length+1,file);
if (size != length){
fputs ("Reading error",stderr);
exit(3);
}
fclose (file);
return buffer;
}
int main (void) {
char *fileName = "test.txt";
char *fileContent = printFile(fileName);
printf("%s",fileContent);
free(fileContent);
return 0;
}
A quick fix is to use calloc instead of malloc, because it zeros the returned bytes
So I replaced:
buffer = malloc(length+1);
with:
buffer = calloc(length,sizeof(char*));
And valgrind doesn't complain:
==7897== Memcheck, a memory error detector
==7897== Copyright (C) 2002-2013, and GNU GPL'd, by Julian Seward et al.
==7897== Using Valgrind-3.10.1 and LibVEX; rerun with -h for copyright info
==7897== Command: ./program
==7897==
The world is not enought and michi is the only one who's not agree.
==7897==
==7897== HEAP SUMMARY:
==7897== in use at exit: 0 bytes in 0 blocks
==7897== total heap usage: 2 allocs, 2 frees, 1,096 bytes allocated
==7897==
==7897== All heap blocks were freed -- no leaks are possible
==7897==
==7897== For counts of detected and suppressed errors, rerun with: -v
==7897== ERROR SUMMARY: 0 errors from 0 contexts (suppressed: 0 from 0)
My question is, why does malloc produce that error and how to avoid calloc.
Do I have some codding problem here or is just malloc?
.
.
EDIT:
if I change:
size = fread (buffer,1,length+1,file);
with:
size = fread (buffer,1,length,file);
I get:
==7985== Memcheck, a memory error detector
==7985== Copyright (C) 2002-2013, and GNU GPL'd, by Julian Seward et al.
==7985== Using Valgrind-3.10.1 and LibVEX; rerun with -h for copyright info
==7985== Command: ./program
==7985==
==7985== Invalid read of size 1
==7985== at 0x4E864B2: vfprintf (vfprintf.c:1642)
==7985== by 0x4E8CC38: printf (printf.c:33)
==7985== by 0x40074C: main (program.c:44)
==7985== Address 0x52022f4 is 0 bytes after a block of size 68 alloc'd
==7985== at 0x4C2BBA0: malloc (in /usr/lib/valgrind/vgpreload_memcheck-amd64-linux.so)
==7985== by 0x4008A6: printFile (program.c:22)
==7985== by 0x40073A: main (program.c:42)
==7985==
The world is not enought and michi is the only one who's not agree.
==7985==
==7985== HEAP SUMMARY:
==7985== in use at exit: 0 bytes in 0 blocks
==7985== total heap usage: 2 allocs, 2 frees, 620 bytes allocated
==7985==
==7985== All heap blocks were freed -- no leaks are possible
==7985==
==7985== For counts of detected and suppressed errors, rerun with: -v
==7985== ERROR SUMMARY: 1 errors from 1 contexts (suppressed: 0 from 0)
You print the file content read into your buffer but nothing can ensure that the buffer contains a NUL char, so valgrind complains because printf parse your data until NUL (jump or move depends on uninitialised value(s)). Using calloc tells valgrind that you are more precautious...
Your string must be NUL-terminated. Without it, the program has undefined behaviour, which valgrind rightfully reports.
The easiest way to NUL-terminate the string is:
size = fread (buffer,1,length,file); /* no need to specify useless extra char */
/* it will never be read */
... /* check for errors here */
buffer[length] = '\0'; /* <--- null termination */
calloc fills the entire buffer with NUL characters, but it's a waste of cycles. You only need one.
Memory obtained via malloc() is uninitialized. That's intentional. The workarounds are to use calloc() instead or to initialize that memory obtained via malloc() before you read from it. Under some circumstances you can initialize only part of it, and often you have better initial values available than all zeroes.
Your particular error is only peripherally related to that, however. You do initialize most of the buffer, via fread(), but you allocate one more byte than the file is long, and fread() does not store anything in that last byte. It looks like maybe you intended to add a '\0' terminator, but forgot. It's that last byte that valgrind complains about.
In this case, the memory-clearing performed by calloc() mostly serves no purpose, as you are about to overwrite all bytes in the buffer but one. But it does initialize that last byte, too, which turns out to save you several kinds of trouble when you fail to initialize it any other way.

Valgrind Reports Invalid Realloc

I'm trying to backfill my knowledge of C memory management. I've come from a mostly scripting and managed background, and I want to learn more about C and C++. To that end I've been reading a few books, including one which included this example of using realloc to trim a string of whitespace:
#include <stdio.h>
#include <stdlib.h>
#include <string.h>
char* trim(char* phrase)
{
char* old = phrase;
char* new = phrase;
while(*old == ' ') {
old++;
}
while(*old) {
*(new++) = *(old++);
}
*new = 0;
return (char*)realloc(phrase, strlen(phrase)+1);
}
int main ()
{
char* buffer = (char*)malloc(strlen(" cat")+1);
strcpy(buffer, " cat");
printf("%s\n", trim(buffer));
free(buffer);
buffer=NULL;
return 0;
}
I dutifully copied the example, and compiled with c99 -Wall -Wpointer-arith -O3 -pedantic -march=native. I don't get any compile errors, and the app runs and does what's promised in the book, but when I run it against valgrind I get an error about invalid realloc.
==21601== Memcheck, a memory error detector
==21601== Copyright (C) 2002-2013, and GNU GPL'd, by Julian Seward et al.
==21601== Using Valgrind-3.10.0.SVN and LibVEX; rerun with -h for copyright info
==21601== Command: ./trim
==21601==
==21601== Invalid free() / delete / delete[] / realloc()
==21601== at 0x402B3D8: free (in /usr/lib/valgrind/vgpreload_memcheck-x86-linux.so)
==21601== by 0x804844E: main (in /home/mo/programming/learning_pointers/trim)
==21601== Address 0x4202028 is 0 bytes inside a block of size 6 free'd
==21601== at 0x402C324: realloc (in /usr/lib/valgrind/vgpreload_memcheck-x86-linux.so)
==21601== by 0x80485A9: trim (in /home/mo/programming/learning_pointers/trim)
==21601== by 0x804842E: main (in /home/mo/programming/learning_pointers/trim)
==21601==
==21601==
==21601== HEAP SUMMARY:
==21601== in use at exit: 4 bytes in 1 blocks
==21601== total heap usage: 2 allocs, 2 frees, 10 bytes allocated
==21601==
==21601== 4 bytes in 1 blocks are definitely lost in loss record 1 of 1
==21601== at 0x402C324: realloc (in /usr/lib/valgrind/vgpreload_memcheck-x86-linux.so)
==21601== by 0x80485A9: trim (in /home/mo/programming/learning_pointers/trim)
==21601== by 0x804842E: main (in /home/mo/programming/learning_pointers/trim)
==21601==
==21601== LEAK SUMMARY:
==21601== definitely lost: 4 bytes in 1 blocks
==21601== indirectly lost: 0 bytes in 0 blocks
==21601== possibly lost: 0 bytes in 0 blocks
==21601== still reachable: 0 bytes in 0 blocks
==21601== suppressed: 0 bytes in 0 blocks
==21601==
==21601== For counts of detected and suppressed errors, rerun with: -v
==21601== ERROR SUMMARY: 2 errors from 2 contexts (suppressed: 0 from 0)
So please help me understand why it's consider an invalid realloc. Is the example crap? Is there something I'm missing? I know that according to the specs, realloc expects the pointer to have been created previously by malloc, so is it because the realloc is in another function? Or is valgrind confused because they're in separate functions? I'm not a complete idiot (most days), but right now I kind of feel like one for not seeing the issue.
Thanks in advance!
You're trying to free the original pointer, not the reallocd one. You can fix it by:
buffer = trim(buffer)

Segfault on `mkl_malloc`

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.

Resources