string close causes SIGSEGV

Discussion in 'C++' started by Lacek, Apr 18, 2012.

  1. Lacek

    Lacek Guest

    Dear All,
    I have run into a problem when closing a string. In particular I open
    a ofstream, I write about 40 lines of numbers. After that I close the
    stream:

    file.close();

    but that line seems to cause a SIGSEGV. THis is confirmed by a
    debugger:

    Program received signal SIGSEGV, Segmentation fault.
    0x00007ffff73151a8 in _int_free (av=0x7ffff76361c0, p=0x636b00) at
    malloc.c:4973
    4973 malloc.c: Nie ma takiego pliku ani katalogu.
    in malloc.c
    (gdb) bt
    #0 0x00007ffff73151a8 in _int_free (av=0x7ffff76361c0, p=0x636b00) at
    malloc.c:4973
    #1 0x00007ffff73189cc in __GI___libc_free (mem=<optimized out>) at
    malloc.c:3738
    #2 0x00007ffff7304365 in _IO_new_fclose (fp=0x636d70) at iofclose.c:
    88
    #3 0x00007ffff7b4abc0 in std::__basic_file<char>::close() () from /
    usr/lib/x86_64-linux-gnu/libstdc++.so.6
    #4 0x00007ffff7b4e411 in std::basic_filebuf<char,
    std::char_traits<char> >::close() () from /usr/lib/x86_64-linux-gnu/
    libstdc++.so.6
    #5 0x00007ffff7b4ff9d in std::basic_ofstream<char,
    std::char_traits<char> >::close() () from /usr/lib/x86_64-linux-gnu/
    libstdc++.so.6
    #6 0x000000000040478e in main ()

    Compiler is:
    gcc version 4.6.1 (Ubuntu/Linaro 4.6.1-9ubuntu3)

    is it something obvious? This is a very last instruction in the code.
    I suppose that bugs totaly unrelated to io cause that instruction it
    to fail (overwriting stream's memory or sth like that ) and my code
    requires a general debugging (its quite fresh), but perhaps I am
    wrong.

    Regards,
    Mateusz ÅÄ…cki
     
    Lacek, Apr 18, 2012
    #1
    1. Advertising

  2. Lacek <> wrote:
    > I have run into a problem when closing a string. In particular I open
    > a ofstream, I write about 40 lines of numbers. After that I close the
    > stream:


    > file.close();


    > but that line seems to cause a SIGSEGV. THis is confirmed by a
    > debugger:


    > Program received signal SIGSEGV, Segmentation fault.
    > 0x00007ffff73151a8 in _int_free (av=0x7ffff76361c0, p=0x636b00) at
    > malloc.c:4973
    > 4973 malloc.c: Nie ma takiego pliku ani katalogu.
    > in malloc.c
    > (gdb) bt
    > #0 0x00007ffff73151a8 in _int_free (av=0x7ffff76361c0, p=0x636b00) at
    > malloc.c:4973
    > #1 0x00007ffff73189cc in __GI___libc_free (mem=<optimized out>) at
    > malloc.c:3738
    > #2 0x00007ffff7304365 in _IO_new_fclose (fp=0x636d70) at iofclose.c:
    > 88
    > #3 0x00007ffff7b4abc0 in std::__basic_file<char>::close() () from /
    > usr/lib/x86_64-linux-gnu/libstdc++.so.6
    > #4 0x00007ffff7b4e411 in std::basic_filebuf<char,
    > std::char_traits<char> >::close() () from /usr/lib/x86_64-linux-gnu/
    > libstdc++.so.6
    > #5 0x00007ffff7b4ff9d in std::basic_ofstream<char,
    > std::char_traits<char> >::close() () from /usr/lib/x86_64-linux-gnu/
    > libstdc++.so.6
    > #6 0x000000000040478e in main ()


    > Compiler is:
    > gcc version 4.6.1 (Ubuntu/Linaro 4.6.1-9ubuntu3)


    > is it something obvious? This is a very last instruction in the code.
    > I suppose that bugs totaly unrelated to io cause that instruction it
    > to fail (overwriting stream's memory or sth like that ) and my code
    > requires a general debugging (its quite fresh), but perhaps I am
    > wrong.


    You're correct - this is extremely unlikely to be a result
    of some bug in close() etc. It looks like a typical memory
    corruption problem which can be anywhere within your code
    executed before the close() call.

    If inspection of your code doesn't result in you finding the
    bug you could try the 'valgrind' program to help you to find
    the reasons.
    Regards, Jens
    --
    \ Jens Thoms Toerring ___
    \__________________________ http://toerring.de
     
    Jens Thoms Toerring, Apr 18, 2012
    #2
    1. Advertising

  3. Lacek <> wrote:
    > Compiler is:
    > gcc version 4.6.1 (Ubuntu/Linaro 4.6.1-9ubuntu3)


    Compile using the option -D_GLIBCXX_DEBUG and then try again.

    If that doesn't help catching the actual problem, run the program
    using valgrind.
     
    Juha Nieminen, Apr 18, 2012
    #3
  4. Lacek

    Gof Guest

    Drew Lawson <> wrote:

    > Almost certainly the reason that line resulted in a SIGSEGV is that
    > the object "file" was trashed before that line was executed.


    The same came to my mind - I've experienced it.

    Consider the code:

    std::string *a = new std::string("test");
    std::string &b = *a;
    delete a;
    b.clear();

    --
    Gof
     
    Gof, Apr 19, 2012
    #4
    1. Advertising

Want to reply to this thread or ask your own question?

It takes just 2 minutes to sign up (and it's free!). Just click the sign up button to choose a username and then you can ask your own questions on the forum.
Similar Threads
  1. Xavier Osa
    Replies:
    0
    Views:
    668
    Xavier Osa
    Jan 9, 2004
  2. Frank
    Replies:
    0
    Views:
    2,148
    Frank
    Aug 5, 2003
  3. manoj
    Replies:
    0
    Views:
    1,211
    manoj
    Jun 25, 2004
  4. Morris Dovey

    gdb SIGSEGV

    Morris Dovey, Feb 12, 2004, in forum: C Programming
    Replies:
    3
    Views:
    1,039
    Mark McIntyre
    Feb 14, 2004
  5. Iñaki Baz Castillo
    Replies:
    7
    Views:
    952
    Iñaki Baz Castillo
    Jan 12, 2010
Loading...

Share This Page