mudflap zgłasza zrzut rdzenia podczas używania operatora new() do przydzielania pamięci

Question

Oto mój fragment kodu.

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

gdy skompilowany z MUDFLAP jak

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

Ale gdy skompilowany bez opcji MUDFLAP nie rzucać zrzutu. Jestem nowy w błotniste. Uprzejmie powiedz, czy używam mudflap w niewłaściwy sposób.

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 pełne Coredump

rdzeń został wygenerowany przez `./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

próbka kompiluje As-Czy na moim kompilatora (Solaris na x86), ale tak naprawdę, to jest tak proste, że platforma nie powinna zrobić różnicę. Jak napisano, twój kod powinien się kompilować i uruchamiać wszędzie. Wydaje się, że jest to wada MudFlap.

nie mam dostępu do MUDFLAP w moim obecnym środowisku, ale tutaj jest coś, co może umożliwić Ci uniknąć problemu sumie:

#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; 
} 

Robię dziką przypuszczenie, że „ukrywa” dynamiczna alokacja wewnątrz inicjalizacji inteligentnego wskaźnika oszukać MudFlap.

Domyślam się, że twój fragment to twoje uproszczenie rzeczywistego problemu. Chociaż nie mam pojęcia, dlaczego nawet uproszczona wersja nie skompilowałaby się w twoim środowisku (powinno), powyższe rozwiązanie ma tę zaletę, że nie musisz martwić się usunięciem wskaźnika, jednak duży jest zakres rzeczywisty.

Z drugiej strony może MudFlap jest naprawdę sprytny i próbuje zmusić cię do korzystania z RAII. Być może ma gdzieś jakieś ustawienie konfiguracyjne, które pozwala ci określić, które chcesz używać i zarządzać surowymi wskaźnikami. Niezależnie od przypadku, dobrze by było, gdybyś zastosował podejście inteligentnego wskaźnika.

Wypróbuj i daj nam znać, jeśli to pomaga.