C++ buggy code - new/delete/ifstream/valgrind. Please help I'm a newbie!!

[kathleen]

Hi there, I'm new to this forum & to programming in general, and am really stuck with a piece of buggy code. Can anyone help? I have several problems which may or may not be related. I have written a piece of code in Visual Studio and now have to get it to run under Linux. Here is the problematic section:

ifstream* seq_input = new ifstream(fname.c_str());
if(seq_input->is_open()==false) {cerr << "File not found";exit (1);}
int i, clen=2, pos, str;
struct data *ndata;
struct sequence *new_seq;
ndata=new data;    
ndata->maxlseq=0;
ndata->nseq=0; 
ndata->type=type;
ndata->seqs=new sequence*;
while(!seq_input->eof()) { str = seq_input->get(); if ((char)str == '>'){
string name;
getline(*seq_input, name);
int namesizing=name.size();
new_seq= new sequence;
new_seq->seq=new int[clen];
new_seq->name=new char[namesizing];
new_seq->length = 0;
new_seq->namesize=0;            
new_seq->namesize=namesizing;
ndata->nseq++;
ndata->seqs[ndata->nseq]=new_seq;
pos=0;
 }
else if (str == ' ' || str =='\t' || str == '\n') ;  
else if (ndata->type==1){pos++;
switch(str) {
case '?': case '-': 
ndata->seqs[ndata->nseq]->seq[pos]=0;
break;
 }
ndata->seqs[ndata->nseq]->length = pos;
 }
if (pos>(clen-10)) {clen *= 2;
ndata->seqs[ndata->nseq]->seq = (int *) realloc(ndata->seqs[ndata->nseq]->seq, clen*sizeof(int));
 }
if (ndata->seqs[ndata->nseq]->length > ndata->maxlseq) {ndata->maxlseq=ndata->seqs[ndata->nseq]->length;
 }
ndata->seqs[ndata->nseq]->length-=1;  
seq_input->close();  
delete seq_input;
 

Problem #1: Under Visual Studio, I am having problems deleting the pointer to seq_input. I have recently done some memory leak debugging and this is the only leak left. With this code the program crashes on delete seq_input with the error message 'unhandled exception/access violation'. This occurs on the core code line 'sizeNext=pNext->sizeFront'. Any ideas as to why this is happening?

Problem #2: Under Unix command line, the program crashes at the end of the for loop on the line pos=0 with the error message double free or corruption. I haven't deleted anything by this point, so have no idea how to fix this.

Problem 3: To investigate these problems further I tried to download Valgrind but I am having trouble running my (compiled under unix) program on it, it gives me the error message 'can only handle 32-bit executables'

Any suggestions on any of these problems would be hugely appreciated. PS. I know I'm not supposed to use realloc with new/delete. Do you think this is the problem? My coding capabilities don't stretch to working out how not to use it. If I use a vector class instead I can't get it into the structure where it needs to be!

Many thanks...... :)

[Banfa]

Problem #1: Under Visual Studio, I am having problems deleting the pointer to seq_input. I have recently done some memory leak debugging and this is the only leak left. With this code the program crashes on delete seq_input with the error message 'unhandled exception/access violation'. This occurs on the core code line 'sizeNext=pNext->sizeFront'. Any ideas as to why this is happening?

The posted code does not contain sizeNext=pNext->sizeFront but the other errors you have(probem 2) are so serious that you should fix them first as they are producing undefined behaviour (which is bad).

Problem #2: Under Unix command line, the program crashes at the end of the for loop on the line pos=0 with the error message double free or corruption. I haven't deleted anything by this point, so have no idea how to fix this.

The problem is with the code line

ndata->seqs[ndata->nseq]=new_seq;

you have new'd ndata->seqs as

ndata->seqs=new sequence*;

This is an array of 1 entries for seqs so in the first line if ndata->nseq is anything other than 0 you are writing to unallocated memory. You might be better off having a linked list, list or vector of sequences rather than trying to dynamically allocat this array, which you don't know your required size of.

You also do not protect against the case of pos going higher than clen which would also result in a write to unallocated memory.

Problem 3: To investigate these problems further I tried to download Valgrind but I am having trouble running my (compiled under unix) program on it, it gives me the error message 'can only handle 32-bit executables'

I have no experience with this utility but I would guess that maybe your system is 16bit, or can handle 16bit code and you have compiled using a compiler or compile options that produce 16 bit code. Check your compiler documentation.

[kathleen]

Hi Banfa,
Thanks for your reply,

The posted code does not contain sizeNext=pNext->sizeFront

Sorry I should have been more clear, this code originates not from my code but from Visual Studio's SBHEAP.C file. I agree with you though that there is unpredictable behaviour going on and that that is the main priority.

The problem is with the code line

ndata->seqs[ndata->nseq]=new_seq;

you have new'd ndata->seqs as

ndata->seqs=new sequence*;

This is an array of 1 entries for seqs so in the first line if ndata->nseq is anything other than 0 you are writing to unallocated memory.

I forgot to mention that data and sequence are both defined as structures in my .h files:

struct sequence{char *name
int namesize
int length
int *seq
 };
struct data{int nseq
int maxlseq
struct sequence **seqs
int type
 };
 

I'm not sure whether this makes a difference to what you are saying about ndata->seqs being an array of one. I was under the impression that ndata->seqs and new_seq were the same type (structures), and this line maps one onto the other sequentially through the while loop, and size of new_seq determines the size of ndata->seqs. This code does work in visual studio so it isn't something immediately obvious that is wrong...but maybe unix just doesn't get this :o .

You might be better off having a linked list, list or vector of sequences rather than trying to dynamically allocat this array, which you don't know your required size of. You also do not protect against the case of pos going higher than clen which would also result in a write to unallocated memory.

I will do some more investigation into this, thank you.

I have no experience with this utility but I would guess that maybe your system is 16bit, or can handle 16bit code and you have compiled using a compiler or compile options that produce 16 bit code. Check your compiler documentation.

I am using the g++ compiler under Linux x86. Do you know how I could check whether it is producing 16 bit code? Sorry for all the ignorance :o - and thanks again for your help

[Banfa]

Sorry been trying to get back to this thread but getting distracted by other things (babies, life etc :D)

Have you managed to fix your problems yet or do you still need some help?