|
From: Stephen L. <sl...@al...> - 2007-12-07 23:20:11
|
Hi,
I am totally new to Valgrind and I probably should have started using it long
before I wrote 9,000 lines of code, but here I am on a tight deadline
for a project for NASA:
When I run Valgrind in verbose mode on the following main() program:
int main(int argc, char *argv[]){
////////
////////
////////
// These user-defined structures pass arguments back and forth between
// routines and back to the main program.
// These structures are set by the calling program (Data Analysis Director)
struct INPUT_DATA inpData;
struct COEF_LIST coeffCfgList;
struct ONOFF_DATA onoffData;
// These parameters define external file name information.
char inputFilename[FILE_NAME_SIZE];
char outputFilename[FILE_NAME_SIZE];
char coeffFilename[FILE_NAME_SIZE];
char diagFilename[FILE_NAME_SIZE];
char coeffCfgFilename[FILE_NAME_SIZE];
char prevEventsFilename[FILE_NAME_SIZE];
char scratchFilename[FILE_NAME_SIZE];
int testCase, j, k, n, results;
int maxNumCases;
int len, sLen;
int argLen;
int numPMTLines;
int pmtDataFound;
int coeffCfgFound;
int startIndex;
int endIndex;
// These arrays define various choices of Gas Coefficients files.
double humList[NUM_H2O] = H2O_LIST;
double tempList[NUM_TEMP] = TEMP_LIST;
int useOneCoeffFile = 1;
* * *
<blah, blah, blah>
return 0;
}
where
H2O_LIST and TEMP_LIST and the following #defines
#define NUM_H2O 4
#define H2O_LIST {7000.0, 10000.0, 15000.0, 20000.0};
#define NUM_TEMP 3
#define TEMP_LIST {23.5, 26.0, 27.5};
and these are fairly involved customized data structures:
struct INPUT_DATA inpData;
struct COEF_LIST coeffCfgList;
struct ONOFF_DATA onoffData;
Looking at the Valigrind output below, I seem to be violating something on the
very first line of the program (main declaration).
Also each time in the declaration section that I assign a value AND in the
main body of code that I assign a value, I get the Invalid Write error
messages - EVERYWHERE.
FYI -
Line 102 is the main() declaration statement
Line 136 is the H2O_LIST declaration
Line 137 is the TEMP_LIST declaration
Line 139 is the UseOneCoeffFile parameter declaration.
Have I overlooked something blindingly obvious?
I did compile with the -g option.
My Valgrind line is as follows:
valgrind --leak-check=yes -v
where "ap" is the executable program, which does appear to be running.
==30031== Memcheck, a memory error detector.
==30031== Copyright (C) 2002-2006, and GNU GPL'd, by Julian Seward et al.
==30031== Using LibVEX rev 1658, a library for dynamic binary translation.
==30031== Copyright (C) 2004-2006, and GNU GPL'd, by OpenWorks LLP.
==30031== Using valgrind-3.2.1-Debian, a dynamic binary instrumentation
framework.
==30031== Copyright (C) 2000-2006, and GNU GPL'd, by Julian Seward et al.
==30031==
--30031-- Command line
--30031-- ./ap
--30031-- Startup, with flags:
--30031-- --leak-check=yes
--30031-- -v
--30031-- Contents of /proc/version:
--30031-- Linux version 2.6.20-16-generic (root@terranova) (gcc version
4.1.2 (Ubuntu 4.1.2-0ubuntu4)) #2 SMP Fri Aug 31 00:55:27 UTC 2007
--30031-- Arch and hwcaps: X86, x86-sse1-sse2
--30031-- Valgrind library directory: /usr/lib/valgrind
--30031-- Reading syms from /lib/ld-2.5.so (0x4000000)
--30031-- Reading debug info from /lib/ld-2.5.so...
--30031-- ... CRC mismatch (computed 2CBFF452 wanted 4F5ED783)
--30031-- object doesn't have a symbol table
--30031-- Reading syms from /home/lab/enose/c/src/ap/ap (0x8048000)
--30031-- Reading syms from /usr/lib/valgrind/x86-linux/memcheck (0x38000000)
--30031-- object doesn't have a dynamic symbol table
--30031-- Reading suppressions file: /usr/lib/valgrind/default.supp
--30031-- Reading syms from /usr/lib/valgrind/x86-linux/vgpreload_core.so
(0x401D000)
--30031-- Reading syms from /usr/lib/valgrind/x86-linux/vgpreload_memcheck.so
(0x401F000)
--30031-- Reading syms from /lib/tls/i686/cmov/libm-2.5.so (0x4033000)
--30031-- Reading debug info from /lib/tls/i686/cmov/libm-2.5.so...
--30031-- ... CRC mismatch (computed 01B4F367 wanted BBAD3DFC)
--30031-- object doesn't have a symbol table
--30031-- Reading syms from /lib/tls/i686/cmov/libc-2.5.so (0x405A000)
--30031-- Reading debug info from /lib/tls/i686/cmov/libc-2.5.so...
--30031-- ... CRC mismatch (computed B8328793 wanted 47732E66)
--30031-- object doesn't have a symbol table
--30031-- REDIR: 0x40C7FA0 (rindex) redirected to 0x40221C0 (rindex)
==30031== Warning: client switching stacks? SP change: 0xBE9A68DC -->
0xBE73E300
==30031== to suppress, use: --max-stackframe=2524636 or greater
==30031== Invalid write of size 4
==30031== at 0x80487CA: main (ap.c:102)
==30031== Address 0xBE73E39C is on thread 1's stack
==30031==
==30031== Invalid read of size 4
==30031== at 0x80487D0: main (ap.c:102)
==30031== Address 0xBE73E39C is on thread 1's stack
==30031==
==30031== Invalid write of size 4
==30031== at 0x80487D9: main (ap.c:102)
==30031== Address 0xBE73E3A4 is on thread 1's stack
==30031==
==30031== Invalid write of size 4
==30031== at 0x80487E6: main (ap.c:102)
==30031== Address 0xBE9A68D4 is on thread 1's stack
==30031==
==30031== Invalid write of size 8
==30031== at 0x80487F1: main (ap.c:136)
==30031== Address 0xBE73EB28 is on thread 1's stack
==30031==
==30031== Invalid write of size 8
==30031== at 0x80487FD: main (ap.c:136)
==30031== Address 0xBE73EB30 is on thread 1's stack
==30031==
==30031== Invalid write of size 8
==30031== at 0x8048809: main (ap.c:136)
==30031== Address 0xBE73EB38 is on thread 1's stack
==30031==
==30031== Invalid write of size 8
==30031== at 0x8048815: main (ap.c:136)
==30031== Address 0xBE73EB40 is on thread 1's stack
==30031==
==30031== Invalid write of size 8
==30031== at 0x8048821: main (ap.c:137)
==30031== Address 0xBE73EB48 is on thread 1's stack
==30031==
==30031== Invalid write of size 8
==30031== at 0x804882D: main (ap.c:137)
==30031== Address 0xBE73EB50 is on thread 1's stack
Any insights would be greatly appreciated.
Thanks!
Steve Licata
|
|
From: Julian S. <js...@ac...> - 2007-12-07 23:36:03
|
The short answer is, do what it says: > ==30031== to suppress, use: --max-stackframe=2524636 or greater The longer answer is, all this complaining happened because you've got a lot of stuff as local variables. At least one function has 2524636 or more bytes of local variables. You would be well advised to change stack allocated arrays into ones allocated by malloc/free, because: 1. Having large amounts of stuff on the stack is bad news; it can lead to stack overflows especially in threaded programs, which can be hard to track down, and 2. Valgrind's Memcheck tool can do a much better job of checking for access anomalies, etc, on malloc'd data. J |