Pavel Shevaev wrote:

Folks, I'm trying to spot a memory corruption error in my application using ElectricFence[1] and I'm facing really weird segfaults in boost::filesystem. I don't really believe it is boost::filesystem which causes a seg.fault but rather my improper usage of ElectricFence.

Here is the most interesting part of the core dump:

#0 0x00007f2b4aa1c517 in kill () from /lib/libc.so.6 #1 0x000000000048f46b in on_signal (s=4) at main.cpp:180 #2 <signal handler called> #3 0x00007f2b4aa1c517 in kill () from /lib/libc.so.6 #4 0x00007f2b4b4e746f in ?? () from /usr/lib/libefence.so.0 #5 0x00007f2b4b4e8290 in _eff_deallocate () from /usr/lib/libefence.so.0 #6 0x00007f2b4b4e884e in _eff_allocate () from /usr/lib/libefence.so.0 #7 0x00007f2b4b4e7288 in operator new () from /usr/lib/libefence.so.0 #8 0x00007f2b4b27d711 in std::string::_Rep::_S_create () from /usr/lib/gcc/x86_64-pc-linux-gnu/4.3.3/libstdc++.so.6 #9 0x00007f2b4b27e0d5 in ?? () from /usr/lib/gcc/x86_64-pc-linux-gnu/4.3.3/libstdc++.so.6 #10 0x00007f2b4b27e213 in std::basic_string<char, std::char_traits<char>, std::allocator<char> >::basic_string () from /usr/lib/gcc/x86_64-pc-linux-gnu/4.3.3/libstdc++.so.6 #11 0x00007f2b4cbaa81e in boost::filesystem::detail::dir_itr_first () from /home/game/hg/master_49100/shared/scripts/../lib/boost/build/lib/libboost_filesystem-mt.so

Basically the following line in my app cases the seg.fault:

boost::filesystem::directory_iterator dir_iter(path);

Inspecting path variable under gdb shows it's ok and actuall directory exists.

Here is some information about my application:

* built with gcc-4.3.3 * runs under linux-2.6.29-gentoo * uses boost-1.35 * boost is built with options: ./bjam link=shared --build-type=minimal --layout=system --toolset=gcc * ElectricFence built from gentoo package efence-2.4.13-r1

The question is whether there are any special boost build options which should be used with ElectricFence.

None that I know. You can add variant=debug but that's no really specific to efence. Sorry for not being overly helpful, Volodya