[filesystem] Strange seg.faults of boost::filesystem under ElectricFence
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
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
::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
The problem with boost::filesystem is now gone after migrating to duma[1] instead of ElectricFence. duma is a an actively developed fork of ElectricFence(which is pretty out-dated).
None that I know. You can add variant=debug but that's no really specific to efence.
Thanks for the tip anyway :) [1] http://duma.sourceforge.net -- Best regards, Pavel
participants (2)
-
Pavel Shevaev
-
Vladimir Prus