Originally Posted by
brewbuck
So, the value 0x0805bd68 looks like a pointer. Do you have a dynamic array somewhere which is an array of pointers? You are probably overflowing that array.
I actually have an array of pointers. I use two and are structured as arrays of strings dynamically allocated. This is good start because I actually modified one of them recently. I'll check on that tomorrow to begin with. Thanks for the hint.
This is the sort of thing that Valgrind is supposed to catch. How are you compiling your program in the failing case? How are you compiling it to run through Valgrind? Are you using different switches in each case? And how exactly are you invoking Valgrind?
I compile my code with the following makefile (See below), and invoke valgrind in its simplest way:
Code:
valgrind ./myexe.a [input_arguments]
Code:
# Makefile for the code PanelMethod.c
# Varialble Definitions and Flags:
CC = gcc #Compiler is gcc
LD = gcc -lm #Linker is gcc also
CFALGS = -Wall -shared
CDEBUG = -g
#CBLAS = -lgsl -lgslcblas
# Linker flags go here. Currently there aren't any, but if we'll switch to
# code optimization, we might add "-s" here to strip debug info and symbols.
LDFLAGS =
# List of source codes and generated object files:
SRCS = main.c READ_INPUT.c READ_MESH.c INIT.c STATE.c ANOMALY.c wrt2initf.c wrt2plotfile.c nrutil.c
OBJS = main.o READ_INPUT.o READ_MESH.o INIT.o STATE.o ANOMALY.o wrt2initf.o wrt2plotfile.o nrutil.o
# ProgRam executable file name:
EXE = meteoIni.a
# Top-level rule, to compile everything
all: $(EXE)
# Rule to Link the program
$(EXE): $(OBJS)
$(LD) -L/usr/local/lib $(OBJS) $(GSLLIB) $(CBLAS) -o $(EXE)
# Rule for all files:
$(OBJS): $(SRCS)
$(CC) $(CFLAGS) $(CDEBUG) -I/usr/include -c $(SRCS)
