Core Dump when closing the ifstream object- why?

This is a discussion on Core Dump when closing the ifstream object- why? within the C++ Programming forums, part of the General Programming Boards category; Hi, I have been getting core dump when closing an ifstream object by calling ObjName.close(); Using this object, i open ...

  1. #1
    Registered User
    Join Date
    Nov 2008
    Posts
    7

    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

  2. #2
    The larch
    Join Date
    May 2006
    Posts
    3,573
    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.
    I might be wrong.

    Thank you, anon. You sure know how to recognize different types of trees from quite a long way away.
    Quoted more than 1000 times (I hope).

  3. #3
    and the hat of wrongness Salem's Avatar
    Join Date
    Aug 2001
    Location
    The edge of the known universe
    Posts
    32,558
    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?
    If you dance barefoot on the broken glass of undefined behaviour, you've got to expect the occasional cut.
    If at first you don't succeed, try writing your phone number on the exam paper.
    I support http://www.ukip.org/ as the first necessary step to a free Europe.

  4. #4
    Registered User
    Join Date
    Nov 2008
    Posts
    7
    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).

  5. #5
    Kernel hacker
    Join Date
    Jul 2007
    Location
    Farncombe, Surrey, England
    Posts
    15,677
    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
    Compilers can produce warnings - make the compiler programmers happy: Use them!
    Please don't PM me for help - and no, I don't do help over instant messengers.

  6. #6
    Registered User
    Join Date
    Nov 2008
    Posts
    7
    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/&#37;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)

  7. #7
    Kernel hacker
    Join Date
    Jul 2007
    Location
    Farncombe, Surrey, England
    Posts
    15,677
    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
    Compilers can produce warnings - make the compiler programmers happy: Use them!
    Please don't PM me for help - and no, I don't do help over instant messengers.

  8. #8
    and the hat of wrongness Salem's Avatar
    Join Date
    Aug 2001
    Location
    The edge of the known universe
    Posts
    32,558
    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.
    If you dance barefoot on the broken glass of undefined behaviour, you've got to expect the occasional cut.
    If at first you don't succeed, try writing your phone number on the exam paper.
    I support http://www.ukip.org/ as the first necessary step to a free Europe.

  9. #9
    Registered User
    Join Date
    Nov 2008
    Posts
    7
    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'.

  10. #10
    Kernel hacker
    Join Date
    Jul 2007
    Location
    Farncombe, Surrey, England
    Posts
    15,677
    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
    Compilers can produce warnings - make the compiler programmers happy: Use them!
    Please don't PM me for help - and no, I don't do help over instant messengers.

  11. #11
    Registered User
    Join Date
    Nov 2008
    Posts
    7
    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.

  12. #12
    Kernel hacker
    Join Date
    Jul 2007
    Location
    Farncombe, Surrey, England
    Posts
    15,677
    Quote Originally Posted by Krsh View Post
    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
    Compilers can produce warnings - make the compiler programmers happy: Use them!
    Please don't PM me for help - and no, I don't do help over instant messengers.

Popular pages Recent additions subscribe to a feed

Similar Threads

  1. Resetting a ifstream object after reading the whole file
    By Zeeshan in forum C++ Programming
    Replies: 5
    Last Post: 03-31-2008, 08:03 AM
  2. how to pass an ifstream object to a function
    By chintugavali in forum C++ Programming
    Replies: 14
    Last Post: 12-18-2007, 08:58 PM
  3. gcc inline asm: illegal instruction (core dump)
    By Sargnagel in forum C Programming
    Replies: 4
    Last Post: 10-28-2003, 12:41 PM
  4. how do i get the file pointer in a ifstream object?
    By mickey in forum C++ Programming
    Replies: 2
    Last Post: 10-21-2002, 01:50 AM
  5. Replies: 2
    Last Post: 10-12-2002, 07:44 PM

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21