Results 1 to 5 of 5

Thread: Program crashes on the line: ofstream fout(fname);

  1. #1
    Join Date
    Dec 2006
    Beans
    106

    Program crashes on the line: ofstream fout(fname);

    This is just about the most inexplicable bug I have seen in over 10 years of programming. My program crashes on the line:
    Code:
    ofstream fout(fname);
    with a segfault. I did include fstream. Note that I am compiling the program with -std=c++11. I'm not sure if that changes anything. Here is my makefile:

    CFLAGS=-std=c++11 -c -Wall -Wextra -g

    SimpCont.o : SimpCont.cpp Traffic.h
    g++ $(CFLAGS) SimpCont.cpp

    Traffic.o : Traffic.cpp Traffic.h
    g++ $(CFLAGS) Traffic.cpp

    traffic : Traffic.o SimpCont.o
    g++ Traffic.o SimpCont.o -o traffic

    clean :
    rm -rf *o traffic

    I have properly wrapped the Traffic.h file in

    #ifndef TRAFFIC_H_
    #define TRAFFIC_H_
    ...
    #endif

    Here is the output from gdb:

    Program received signal SIGSEGV, Segmentation fault.
    0x00007ffff72848aa in ?? () from /lib/x86_64-linux-gnu/libc.so.6
    (gdb) bt
    #0 0x00007ffff72848aa in ?? () from /lib/x86_64-linux-gnu/libc.so.6
    #1 0x00007ffff7286f95 in malloc () from /lib/x86_64-linux-gnu/libc.so.6
    #2 0x00007ffff7b3536d in operator new(unsigned long) ()
    from /usr/lib/x86_64-linux-gnu/libstdc++.so.6
    #3 0x00007ffff7b35469 in operator new[](unsigned long) ()
    from /usr/lib/x86_64-linux-gnu/libstdc++.so.6
    #4 0x00007ffff7b89a4c in std::basic_filebuf<char, std::char_traits<char> >::_M_allocate_internal_buffer() () from /usr/lib/x86_64-linux-gnu/libstdc++.so.6
    #5 0x00007ffff7b8a062 in std::basic_filebuf<char, std::char_traits<char> >:pen(char const*, std::_Ios_Openmode) ()
    from /usr/lib/x86_64-linux-gnu/libstdc++.so.6
    #6 0x00007ffff7b8b8d8 in std::basic_ofstream<char, std::char_traits<char> >::basic_ofstream(char const*, std::_Ios_Openmode) ()
    from /usr/lib/x86_64-linux-gnu/libstdc++.so.6
    #7 0x00000000004052e5 in SimpCont::write (this=0x60e100,
    fname=0x7fffffffe545 "TestOut1.txt") at SimpCont.cpp:218
    #8 0x00000000004018ed in main (argc=4, argv=0x7fffffffe248) at Traffic.cpp:26

    Using up a few times gives:

    #7 0x00000000004052e5 in SimpCont::write (this=0x60e100,
    fname=0x7fffffffe545 "TestOut1.txt") at SimpCont.cpp:218
    218 ofstream fout(fname);

    Does anyone have any ideas what could cause this?

  2. #2
    Join Date
    Aug 2010
    Location
    Lancs, United Kingdom
    Beans
    1,588
    Distro
    Ubuntu Mate 16.04 Xenial Xerus

    Re: Program crashes on the line: ofstream fout(fname);

    As you can see, it is crashing in malloc. This suggests that memory has been trampled before you get here. This tallies with crashing on the most innocuous looking line of code. I suggest you try valgrind to try to track it down.

    If it's not that, then I guess it could be something to do with incompatibilities between link time and runtime libraries. However, I wouldn't consider that very likely.

  3. #3
    Join Date
    Dec 2006
    Beans
    106

    Re: Program crashes on the line: ofstream fout(fname);

    Quote Originally Posted by spjackson View Post
    As you can see, it is crashing in malloc. This suggests that memory has been trampled before you get here. This tallies with crashing on the most innocuous looking line of code. I suggest you try valgrind to try to track it down.
    You were right! Thank you immensely for your advice. I had been banging my head for hours trying to figure this out.

  4. #4
    Join Date
    Jul 2014
    Beans
    1

    Re: Program crashes on the line: ofstream fout(fname);

    Hi, I am facing the exact same problem. How did you go about solving it ?

  5. #5
    Join Date
    Jun 2007
    Location
    Maryland, US
    Beans
    6,288
    Distro
    Kubuntu

    Re: Program crashes on the line: ofstream fout(fname);

    Quote Originally Posted by gaurav13 View Post
    Hi, I am facing the exact same problem. How did you go about solving it ?
    Undoubtedly the OP performed a detailed analysis of his code, trying to track down exactly where he had inadvertently added a bug to the code that was trampling over memory objects that he had allocated or had defined on the stack.

    You should consider doing the same, perhaps, as suggested earlier, with the aid of valgrind.

Bookmarks

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •