Core Dump when closing the ifstream object- why?

Hi,

I have been getting core dump when closing an ifstream object by calling ObjName.close();
Using this object, i open a file in binary mode, and read data in a fixed pattern, the same pattern in which it was written

Code:

ifstream ifs(dfilename , ios::binary);

	if(!(ifs))
        {
          

          cout<<"No file with name "<<fname<<" exists!!"<<endl ;
		  
		  return;

	 }

	 ifs.read(num_arr, sizeof(_eN));
	 
	_evN = *((int *)(num_arr));

	ifs.read(t_eName,101);

	ifs.read(&t_fType,1);

	ifs.read(num_arr,sizeof(t_NFacs));
	
	t_NumberOfFacs=*((int *)(num_arr));

 similarly there are certain more reads in some for loops after which 
 
 i close the object :

 ifs.close();

the core dump back trace is pointing to ifs.close()

Can you please help me in tracing out this problem.

KK

Perhaps the declarations of what you are reading data into, and a sample input might also be relevant?

The standard library implementation usually isn't at fault, unless perhaps the rest of the code is corrupting memory somehow.

Of course those num_arr and dubious casts are in no way suspicious at all.

is num_arr even allocated to be big enough for all those reads?

is it sufficiently aligned to allow all those casts?

Thanks for the reply,

the size of the variables that are used to read in the info, are big enough to hold the fixed amount of data that is read.

num_arr is of size 5 ( char num_arr[5]) and

_evN is an integer

t_eName is of size 102

where as t_fType is a char

This code is present in a thread and there are around 50 threads running but no two threads are reading the same file.

This code is working fine when the load is around 50 threads but when the number of threads increases to around 100+ , it spits core dump.


and about the input, the file that is read was actually generated by the reverse process( during the serialization of an object, stripping each file, since it is a binary file, posting the content here may not be a good idea, i can do that ofcourse).

So it sounds very likely that the problem isn't caused directly by the posted code, but by the number of threads in some way.

--
Mats

The back trace of the stack shows the below info.


0xc019a528 in free () from /usr/lib/libc.2
#1 0xc0684594 in operator delete () from /lib/libCsup.2
#2 0xc06f2d50 in streambuf::~streambuf () from /lib/libstream.2
#3 0xc06e7188 in filebuf::~filebuf () from /lib/libstream.2
#4 0xc06e8940 in fstreambase::~fstreambase () from /lib/libstream.2
#5 0xc06e8f48 in ifstream::~ifstream () from /lib/libstream.2
#6 0x2edf4 in RF::deserialize (this=0x765da3b4,
fname=0x6c1c4 "/rapid/ri2/workdir/%d.e") at RF.C:1359
#7 0x2f154 in RThread (attr=0x0) at RThread.C:175
#8 0xc005b168 in __pthread_body () from /usr/lib/libpthread.1
#9 0xc00649ec in __pthread_start () from /usr/lib/libpthread.1


line number 175 is a call to a member function deserialize() of an object (RF) .

line number 1359 is ifs.close() ( closing the ifstream object)

Ok, sounds like you've overwritten some pointer in the fstream, and that causes a problem.
Check your array indices (including the filename generation using sprintf() or similar...).

--
Mats

Since the backtrace ends with free(), it could be anything anywhere.

If you've trashed the memory pool, then any random function at any future point in time is going to crash.

If you've got lots of them, finding out which is responsible can be hard work.

How long does it take to crash with 100 threads - seconds, or hours?

Are you running in the debugger when it crashes, or did you get that info from a core file?

Looking at the memory around the address that free() tried to free, may help you figure out who wrote the data which trashed the memory.

Compiling the program as follows, then running in the debugger would trap the cause.
gcc prog.c -lefence
Electric fence allocates memory which ends in a page boundary, so any overwrites cause a page fault. This is nicely trapped in the debugger.

Or you could try running the code under valgrind. This will spot many other "dubious" use of memory problems for you as well.

I observe that the problem could be with the process stack size.

I had increased the thread stack size in the code for some reason. The process stack size remaining the same, the process is not able to allocate the stack space for the thread when it is getting created, if it is able to do so, at some point it is getting corrupted.

Can this be the reason?

If so, what should i do? i tried increase the stack size in vain. i tried the same with sroot priviledges, which is giving the same error, 'the limit mentioned exceeded the permissible limit'.

I would have thought that the process stack size (which I presume is a megabyte or two) would be sufficient. If it's not, then you probably should consider a different approach, rather than trying to increase the stack.

How are you giving the stacks to each thread - it is of course possible that a thread could overwrite the allocated space in some way, and that this COULD cause the problem you describe - but it could also be caused by MANY other things.

--
Mats

yep, the process stack size is 8MB. but the notable thing is the thread size is around 400 KB ( only the user data, mallocating this part can be done)

I am not explicitly allocating thread stack, but since allocation to a thread is on stack, i assume this goes into the process stack space. So, i think this to be the problem.

Originally Posted by Krsh

yep, the process stack size is 8MB. but the notable thing is the thread size is around 400 KB ( only the user data, mallocating this part can be done)

I am not explicitly allocating thread stack, but since allocation to a thread is on stack, i assume this goes into the process stack space. So, i think this to be the problem.

I hadn't looked carefully at the stack allocation mechanism in pthreads, but it looks like you just give it a size. This, by all likelihood means that either pthreads library or the kernel allocates the space for the stack - and not from the process stack. Either from the normal heap, or some "special" heap.

--
Mats