0

The part of the code which gives rise to the segmentation fault is given below.

ifstream xiFileId(xifile, ios::binary); //xifile is a char * 

//the ii_t class in the following line is taken from http://stackoverflow.com/questions/1855704/c-binary-file-i-o-to-from-containers-other-than-char-using-stl-algorithms written by http://stackoverflow.com/users/14065/loki-astari

ii_t<uint> xi_in(xiFileId);
copy(xi_in, ii_t<uint>(), xi.data()); //xi is a 2D boost::multi_array 

//my efforts to debug

ios::iostate s = xiFileId.rdstate();

if(s & ios::badbit) cout << "bad bit is set" << endl;
if (s & ios::failbit) cout << "fail bit is set" << endl;
if (s & ios::eofbit) cout << "eof bit is set" << endl;
if (s & ios::goodbit) cout << "good bit is set" << endl;

xiFileId.close(); //this line creates the seg violation

It is found that the failbit and eof bit are set. Using valgrind it was found that there is no memory leak for my whole program.

The same code (as above) is repeated for another binary file and a segmentation fault does not arise when closing that file (that file is closed earlier) even though that file also has both fail and eof bit set.

That file closing give rise to segmentation fault is identified by using gdb and the core file, which is given below.

#0  0x00007f16ad99ae50 in __libc_free (mem=0x1b8f930) at malloc.c:3724
3724    malloc.c: No such file or directory.
in malloc.c
(gdb) bt
#0  0x00007f16ad99ae50 in __libc_free (mem=0x1b8f930) at malloc.c:3724
#1  0x00007f16ae1adf0e in std::basic_filebuf<char, std::char_traits<char>   >::_M_destroy_internal_buffer() () from /usr/lib/libstdc++.so.6

#2  0x00007f16ae1af4d4 in std::basic_filebuf<char, std::char_traits<char> >::close() () from /usr/lib/libstdc++.so.6
#3  0x00007f16ae1b133d in std::basic_ifstream<char, std::char_traits<char> >::close() () from /usr/lib/libstdc++.so.6
#4  0x000000000040c119 in main (argc=19, argv=0x7fff05849898) at prediction.cpp:161

If I remove the xiFileId.close(); as the compiler will close the file when it becomes out of scope, the gdb back trace gives the following:

#0  0x00007f97fab81e50 in __libc_free (mem=0x15a7930) at malloc.c:3724
3724    malloc.c: No such file or directory.
in malloc.c
(gdb) bt
#0  0x00007f97fab81e50 in __libc_free (mem=0x15a7930) at malloc.c:3724
#1  0x00007f97fb394f0e in std::basic_filebuf<char, std::char_traits<char> >::_M_destroy_internal_buffer() () from /usr/lib/libstdc++.so.6
#2  0x00007f97fb3964d4 in std::basic_filebuf<char, std::char_traits<char> >::close() () from /usr/lib/libstdc++.so.6
#3  0x00007f97fb39c966 in std::basic_ifstream<char, std::char_traits<char> >::~basic_ifstream() () from /usr/lib/libstdc++.so.6
#4  0x000000000040c184 in main (argc=19, argv=0x7fff59b71918) at prediction.cpp:163

which shows that the ~basic_ifstream() is called and segmentation violation occurs.

Under what conditions a file closing can create a seg violation?

Any ideas on how can I investigate further/fix it?

This code is run on Ubuntu 10.04 and compiled using gcc version 4.4.3 .

suresh

suresh
  • 1,109
  • 1
  • 8
  • 24
  • Try `copy(xi_in, ii_t(), xi.data());`. Also make sure that the recipient is already large enough. – Kerrek SB Nov 04 '11 at 00:13
  • 1
    Can you produce a minimal compilable example that demonstrates the problem. – Martin York Nov 04 '11 at 00:14
  • @KerrekSB yea it was ii_t only - it was typo. thanks – suresh Nov 04 '11 at 00:17
  • @LokiAstari While trying to create a minimal example, I saw that the segmentation fault comes from boost::multi_array. So I have created a minimal example and posted it as a new question here: http://stackoverflow.com/questions/8004456/segmentation-fault-on-boostmulti-array – suresh Nov 04 '11 at 03:03
  • @LokiAstari I removed the ii_t class and instead read from the binary file to a vector and then filled the boost multi-array, every thing works fine...I can send you my code and files which creates this seg fault if needed. I am also curious why this occurs. – suresh Nov 04 '11 at 04:44

1 Answers1

1

The solution is already mentioned in the comments but for the convenience of future readers, it is posted as an answer seperately.

The problem was with the ii_t class and a solution was provided in Segmentation fault on boost::multi_array by https://stackoverflow.com/users/12711/michael-burr

Community
  • 1
  • 1
suresh
  • 1,109
  • 1
  • 8
  • 24