mudflap genera core dump quando si utilizza l'operatore new() per allocare memoria

Question

Ecco lo snippet di codice.

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

se compilato con paraspruzzi come

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

Ma quando compilato opzione paraspruzzi senza di essa non genera core dump. Sono nuovo di mudflap. Dite gentilmente se sto usando mudflap nel modo sbagliato.

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 pieno di coredump

Nucleo è stato generato da `./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

tuo campione compila così come sono sul mio compilatore (Solaris su x86), ma in realtà, è così semplice che la piattaforma non dovrebbe fare la differenza. Come scritto, il tuo codice dovrebbe essere compilato ed eseguito ovunque. Sembrerebbe essere un difetto di MudFlap.

Non ho accesso a MUDFLAP nel mio ambiente attuale, ma qui c'è qualcosa che potrebbe consentire di evitare il problema del tutto:

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

Sto facendo un ipotesi che "nasconde" l'allocazione dinamica all'interno dell'inizializzazione del puntatore intelligente verrà ingannato MudFlap.

Immagino che il tuo frammento di codice sia la tua semplificazione di un problema del mondo reale. Anche se non ho idea del perché anche la versione semplificata non si compili nel proprio ambiente (dovrebbe), la soluzione di cui sopra ha la virtù che non è necessario preoccuparsi di eliminare il puntatore, per quanto grande sia lo scopo del mondo reale.

Quindi, di nuovo, forse MudFlap è davvero intelligente e tenta di forzare l'utilizzo di RAII. Forse ha qualche impostazione di configurazione da qualche parte per consentire di specificare che si desidera utilizzare e gestire i puntatori grezzi. In ogni caso, si sarebbe ben serviti per andare con l'approccio puntatore intelligente, a prescindere.

Provalo e facci sapere se è d'aiuto.