Mudflap produces a core dump when using the new () operator to allocate memory

Question

Here is my code snippet.

int main() { int *var = new int(6); cout<<"Hello\n"; delete var; return 0; } 

when compiling with mudflap as

 $export MUDFLAP_OPTIONS="-print-leaks -mode-check" $g++ test.cpp -fmudflap -lmudflap $./a.out Segmentation fault (core dumped) 

But when compiling without the mudflap option, it does not produce a main dump. I'm new to spray. Tell me if I use a mudguard incorrectly.

FYI:

 $uname -a Linux localhost.localdomain 2.6.18-308.4.1.el5 #1 SMP Wed Mar 28 01:54:56 EDT 2012 x86_64 x86_64 x86_64 GNU/Linux $g++ -v Using built-in specs. COLLECT_GCC=g++ COLLECT_LTO_WRAPPER=/usr/libexec/gcc/x86_64-redhat-linux-gnu/4.7.3/lto-wrapper Target: x86_64-redhat-linux-gnu Configured with: /root/rohit/gcc-4.7.3/configure --prefix=/usr/ Thread model: posix gcc version 4.7.3 (GCC) 

bt full coredump

The kernel was created by `./a.out '.

 Program terminated with signal 11, Segmentation fault. [New process 22176] #0 0x0000003ca5e075c8 in ?? () from /lib64/libgcc_s.so.1 (gdb) bt ful #0 0x0000003ca5e075c8 in ?? () from /lib64/libgcc_s.so.1 No symbol table info available. #1 0x0000003ca5e0882b in _Unwind_Backtrace () from /lib64/libgcc_s.so.1 No symbol table info available. #2 0x0000003c96ce5eb8 in backtrace () from /lib64/libc.so.6 No symbol table info available. #3 0x00002b4acf58b417 in __mf_backtrace (symbols=0x6a51db8, guess_pc=0x2b4acf58d351, guess_omit_levels=2) at /root/rohit/gcc-4.7.3/libmudflap/mf-runtime.c:1981 pc_array = (void **) 0x6a51e00 pc_array_size = 6 remaining_size = <value optimized out> omitted_size = Unhandled dwarf expression opcode 0x9f i = <value optimized out> #4 0x0000000000000002 in ?? () No symbol table info available. #5 0x0000000000000004 in ?? () No symbol table info available. #6 0x0000000000000000 in ?? () No symbol table info available. 

Answer 1

Your sample compiles As-Is into my compiler (Solaris on x86), but in fact it is so simple that the platform should not matter. As written, your code should compile and execute everywhere. It would seem that this was some disadvantage of MudFlap.

I do not have access to MudFlap in my current environment, but there is something here that could allow you to avoid the problem altogether:

 #include <iostream> #include <boost/shared_ptr.hpp> using namespace std; int main() { boost::shared_ptr<int> var (new int(6)); cout << "Hello #" << *var << endl; return 0; } 

I guess that "hiding" dynamic allocation inside smart pointer initialization will fool MudFlap.

I assume that your snippet is a simplification of the real problem. Although I do not know why even a simplified version will not compile in your environment (it should), the above solution has the virtue that you do not need to worry about deleting the pointer, whatever the real reality.

And again, maybe MudFlap is really smart and trying to get you to use RAII. Perhaps it has some configuration setting where you can specify what you want to use and manage the raw pointers. In any case, it would be nice for you to use a smart pointer approach if you like.

Try and let us know if this helps.