|
From: simone m. <sma...@gm...> - 2009-07-13 08:29:32
|
Hi everyone, I was having problems of memory allocation that valgirnd identified as a mismatched number in "malloc/free". Not knowing where the problem could be I tried to not allocate anything in my code and see if there was still a similar error. I realized that valgrind still gave me a mismatched number although I am not actually using malloc and free for this test. Where could the problem be? Does valgrind identify the declaration of a pointer already as if I were to malloc it? I surfed the list to find a similar error from someone else, but although partly similar, I didn't find the same. Apologies in advance if I am re-posting the same. I hope someone can help. Thank you in advance |
|
From: Colin M. <col...@pi...> - 2009-07-13 10:18:04
|
simone marras wrote: > Hi everyone, > > I was having problems of memory allocation that valgirnd identified as > a mismatched number in "malloc/free". Not knowing where the problem > could be I tried to not allocate anything in my code and see if there > was still a similar error. I realized that valgrind still gave me a > mismatched number although I am not actually using malloc and free for > this test. > Where could the problem be? Does valgrind identify the declaration of > a pointer already as if I were to malloc it? > > Simone, Valgrind should give a full backtrace for each error. If you built and linked your program with debug info ( -g option in gcc/g++ ), then the symbol names will be printed, otherwise just the addresses of the functions. What error(s) is valgrind reporting? It is possible that a library that you are using is buggy. If you put some of the output here, I'm sure the we can give you further assistance. Colin S. Miller |
|
From: simone m. <sma...@gm...> - 2009-07-13 10:27:45
|
Hi Colin,
Thanks for replying. Here I send you the main.c written for the test
(no "apparent allocation"), and the valgrind output.
I hope this helps you
thank you in advance,
Simone
--------------------------------------------------------------------------------------------
Valgrind output:
simone-marras-macbook-aero:Source simone$ valgrind ./meteoIni.a
meteoIni.inp agnesi_NH_80kmX19km_dx400mXdz400m_mount1mHeight.msh 2
==18862== Memcheck, a memory error detector.
==18862== Copyright (C) 2002-2009, and GNU GPL'd, by Julian Seward et al.
==18862== Using LibVEX rev 1908, a library for dynamic binary translation.
==18862== Copyright (C) 2004-2009, and GNU GPL'd, by OpenWorks LLP.
==18862== Using valgrind-3.5.0.SVN, a dynamic binary instrumentation framework.
==18862== Copyright (C) 2000-2009, and GNU GPL'd, by Julian Seward et al.
==18862== For more details, rerun with: -v
==18862==
--18862-- ./meteoIni.a:
--18862-- dSYM directory has wrong UUID; consider using --auto-run-dsymutil=yes
###################################################################
# Welcome to MeteoIni!
#
# This code reads in a GID mesh file
# and initializes an atmospheric field on the mesh nodes.
###################################################################
==18862==
==18862== ERROR SUMMARY: 0 errors from 0 contexts (suppressed: 0 from 0)
==18862== malloc/free: in use at exit: 4,436 bytes in 9 blocks.
==18862== malloc/free: 9 allocs, 0 frees, 4,436 bytes allocated.
==18862== For counts of detected errors, rerun with: -v
==18862== searching for pointers to 9 not-freed blocks.
==18862== checked 1,124,356 bytes.
==18862==
==18862== LEAK SUMMARY:
==18862== definitely lost: 0 bytes in 0 blocks.
==18862== indirectly lost: 0 bytes in 0 blocks.
==18862== possibly lost: 0 bytes in 0 blocks.
==18862== still reachable: 0 bytes in 0 blocks.
==18862== suppressed: 4,436 bytes in 9 blocks.
--------------------------------------------------------------------------------------------
main.c
#include "include_.h"
#include "def_thermo.h"
#define MAX_NVARS 20
#define PROB_ENTRIES 5
#define MAX_STR_LENGTH 64
#define MAX_INPUT_ENTRIES 35
#define MAX_NBOUND 4 //Maximum number of boundaries in the domain
#define EPSI 0.000001
int main(int argc, char *argv[])
{
int inode,i,j;
int nsd, nnodes, nelem, nbdy_nodes, max_elnodes;
float height, x_min, x_max, z_min, z_max;
int **CONN;
int *ELTYPE;
float **COORDS;
float **INITV;
int *BFLAG;
float PROBVars[MAX_INPUT_ENTRIES];
const char *BC_flags[MAX_NBOUND] = {"o", "s", "o", "s"};
char *input_file, *msh_file, *msh_generator;
/************************************************/
//Begin:
if(argc <= 3){
//Remember that the first argument of argc is the name of the program
by default,
//thus argc == 1 correswponds to that and the program recognizes that
you did not put any input
printf("\n You did not enter the input file\n");
printf(" Call the program as:\n");
printf("\n ./alya_initialize.a [inputFile] [meshFile] [nsd]\n");
printf("\n [inputFile]: input file with the perturb. characteristics.");
printf("\n [meshFile]: mesh file to read (only. GID for now).\n");
printf(" [nsd] indicates the number of space dimensions (2 ONLY for
now).\n");
printf("\n");
exit(1);
}
else{
printf("\n ###################################################################\n");
printf(" #\t Welcome to MeteoIni!\n #\n");
printf(" #\t This code reads in a GID mesh file\t\n");
printf(" #\t and initializes an atmospheric field on the mesh nodes.\n");
printf(" ###################################################################\n\n");
}
/************************************************/
//If adding new variables, you need to update nvars also!
int nvars = 7;
const char *varnames[] = {"PRESS", "DENSI", "TEMPE", "THETA",
"XVELO_bound", "ZVELO_bound", "EXNER"};
return;
}
On Mon, Jul 13, 2009 at 12:03 PM, Colin Miller<col...@pi...> wrote:
> simone marras wrote:
>> Hi everyone,
>>
>> I was having problems of memory allocation that valgirnd identified as
>> a mismatched number in "malloc/free". Not knowing where the problem
>> could be I tried to not allocate anything in my code and see if there
>> was still a similar error. I realized that valgrind still gave me a
>> mismatched number although I am not actually using malloc and free for
>> this test.
>> Where could the problem be? Does valgrind identify the declaration of
>> a pointer already as if I were to malloc it?
>>
>>
> Simone,
>
> Valgrind should give a full backtrace for each error.
> If you built and linked your program with debug info
> ( -g option in gcc/g++ ), then the symbol names will be printed,
> otherwise just the addresses of the functions.
>
> What error(s) is valgrind reporting?
> It is possible that a library that you are using is buggy.
>
>
> If you put some of the output here, I'm sure the we can give
> you further assistance.
>
> Colin S. Miller
>
>
> ------------------------------------------------------------------------------
> Enter the BlackBerry Developer Challenge
> This is your chance to win up to $100,000 in prizes! For a limited time,
> vendors submitting new applications to BlackBerry App World(TM) will have
> the opportunity to enter the BlackBerry Developer Challenge. See full prize
> details at: http://p.sf.net/sfu/Challenge
> _______________________________________________
> Valgrind-users mailing list
> Val...@li...
> https://lists.sourceforge.net/lists/listinfo/valgrind-users
>
--
Simone Marras, Ph.D. candidate
Barcelona Supercomputing Center
Universitat Politecnica de Catalunya
Avd. Diagonal 647,
Edificio H, planta 10
Barcelona, 08028
SPAIN
Tel.: (+34) 93 4011744
web: www.cranfield.ac.uk/~c086030
|
|
From: Colin M. <col...@pi...> - 2009-07-13 10:56:20
|
simone marras wrote: > Hi Colin, > > Thanks for replying. Here I send you the main.c written for the test > (no "apparent allocation"), and the valgrind output. > I hope this helps you > > thank you in advance, > Simone > > -------------------------------------------------------------------------------------------- > Valgrind output: > > > ==18862== > ==18862== ERROR SUMMARY: 0 errors from 0 contexts (suppressed: 0 from 0) > ==18862== malloc/free: in use at exit: 4,436 bytes in 9 blocks. > ==18862== malloc/free: 9 allocs, 0 frees, 4,436 bytes allocated. > ==18862== For counts of detected errors, rerun with: -v > ==18862== searching for pointers to 9 not-freed blocks. > ==18862== checked 1,124,356 bytes. > ==18862== > ==18862== LEAK SUMMARY: > ==18862== definitely lost: 0 bytes in 0 blocks. > ==18862== indirectly lost: 0 bytes in 0 blocks. > ==18862== possibly lost: 0 bytes in 0 blocks. > ==18862== still reachable: 0 bytes in 0 blocks. > ==18862== suppressed: 4,436 bytes in 9 blocks. > > > Simone, The "suppressed: 4,436 bytes in 9 blocks." line indicates that Valgrind has detected an error but has been told not to report the details. This behaviour is controlled by a suppression file. Since you did not specify a suppressions file, I'd assume it in the default suppression file. (Use valgrind -v to find its name). Therefore, I'd further assume that it is a known bug in a runtime library you are using (possible the stdio) According to the manual, Valgrind tries to force glibc (the C runtime library) to free all its memory by calling __libc_freeres(), I'm not sure why a suppression was used. I can't see a way to tell Valgrind not to use its default suppression file, which would ascertain this for certain. HTH, Colin S. Miller |
|
From: Olly B. <ol...@su...> - 2009-07-14 15:19:57
|
On 2009-07-13, Colin Miller <col...@pi...> wrote:
> According to the manual, Valgrind tries to force glibc (the C runtime
> library) to free all its memory by calling __libc_freeres(), I'm not
> sure why a suppression was used.
I don't think Mac OS X uses glibc, and presumably its C runtime doesn't
have a way to force all memory to be released.
Cheers,
Olly
|
|
From: Colin M. <col...@pi...> - 2009-07-14 17:30:25
|
Olly Betts wrote: > On 2009-07-13, Colin Miller <col...@pi...> wrote: > >> According to the manual, Valgrind tries to force glibc (the C runtime >> library) to free all its memory by calling __libc_freeres(), I'm not >> sure why a suppression was used. >> > > I don't think Mac OS X uses glibc, and presumably its C runtime doesn't > have a way to force all memory to be released. > > Ah, I didn't notice the OP was using a Mac; my Linux-centricism. Colin S. Miller. |
|
From: Nicholas N. <n.n...@gm...> - 2009-07-14 01:50:05
|
On Mon, Jul 13, 2009 at 8:27 PM, simone marras<sma...@gm...> wrote: > ==18862== > ==18862== ERROR SUMMARY: 0 errors from 0 contexts (suppressed: 0 from 0) > ==18862== malloc/free: in use at exit: 4,436 bytes in 9 blocks. > ==18862== malloc/free: 9 allocs, 0 frees, 4,436 bytes allocated. > ==18862== For counts of detected errors, rerun with: -v > ==18862== searching for pointers to 9 not-freed blocks. > ==18862== checked 1,124,356 bytes. > ==18862== > ==18862== LEAK SUMMARY: > ==18862== definitely lost: 0 bytes in 0 blocks. > ==18862== indirectly lost: 0 bytes in 0 blocks. > ==18862== possibly lost: 0 bytes in 0 blocks. > ==18862== still reachable: 0 bytes in 0 blocks. > ==18862== suppressed: 4,436 bytes in 9 blocks. The Mac libc allocates some memory with malloc() but never frees it. There are some suppressions for this in darwin9.supp, which becomes part of default.supp, so that these aren't reported as leaks, because you have no control over them. The moral of the story is: the code you write is not the only code being run. Nick |
|
From: Simone M. <sma...@gm...> - 2009-07-14 05:55:37
|
Hi Nicholas, Thanks for the hint. Good to know all this. Best, S. On Jul 14, 2009, at 3:49 AM, Nicholas Nethercote wrote: > On Mon, Jul 13, 2009 at 8:27 PM, simone > marras<sma...@gm...> wrote: >> ==18862== >> ==18862== ERROR SUMMARY: 0 errors from 0 contexts (suppressed: 0 >> from 0) >> ==18862== malloc/free: in use at exit: 4,436 bytes in 9 blocks. >> ==18862== malloc/free: 9 allocs, 0 frees, 4,436 bytes allocated. >> ==18862== For counts of detected errors, rerun with: -v >> ==18862== searching for pointers to 9 not-freed blocks. >> ==18862== checked 1,124,356 bytes. >> ==18862== >> ==18862== LEAK SUMMARY: >> ==18862== definitely lost: 0 bytes in 0 blocks. >> ==18862== indirectly lost: 0 bytes in 0 blocks. >> ==18862== possibly lost: 0 bytes in 0 blocks. >> ==18862== still reachable: 0 bytes in 0 blocks. >> ==18862== suppressed: 4,436 bytes in 9 blocks. > > The Mac libc allocates some memory with malloc() but never frees it. > There are some suppressions for this in darwin9.supp, which becomes > part of default.supp, so that these aren't reported as leaks, because > you have no control over them. > > The moral of the story is: the code you write is not the only code > being run. > > Nick |