当使用new（）运算符分配内存时，mudflap会抛出核心转储

Question

Here is my code snippet.

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

when compiled with mudflap as

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

But when compiled without mudflap option it doesn't throw core dump. I'm new to mudflap. Kindly tell if I'm using mudflap in wrong way.

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 of coredump

Core was generated 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 on my compiler (Solaris on x86), but really, it is so simple that the platform shouldn't make a difference. As written, your code should compile and run everywhere. It would appear to be some shortcoming of MudFlap.

I don't have access to MudFlap in my current environment but here's something which might enable 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'm making a wild guess that "hiding" the dynamic allocation inside the smart-pointer initialization will trick MudFlap.

I'll guess that your snippet is your simplification of a real-world problem. While I have no clue why even the simplified version wouldn't compile in your environment (it should), the above solution has the virtue that you don't need to worry about deleting the pointer, however large the real-world scope is.

Then again, maybe MudFlap is really smart and attempting to force you to use RAII. Perhaps it has some configuration setting somewhere to let you specify that you want to use and manage raw pointers. Whatever the case, you would be well-served to go with the smart-pointer approach, regardless.

Try it and let us know if it helps.