string close causes SIGSEGV

[Lacek]

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

 

[Jens Thoms Toerring]

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:

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

 

[Juha Nieminen]

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.

 

[Gof]

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();