Strange backtrace - où est l'erreur?

Question

Je développe une application de traitement d'image en C ++. J'ai vu beaucoup d'erreurs de compilation et de traces, mais celle-ci est nouvelle pour moi.

#0  0xb80c5430 in __kernel_vsyscall ()
#1  0xb7d1b6d0 in raise () from /lib/tls/i686/cmov/libc.so.6
#2  0xb7d1d098 in abort () from /lib/tls/i686/cmov/libc.so.6
#3  0xb7d5924d in ?? () from /lib/tls/i686/cmov/libc.so.6
#4  0xb7d62276 in ?? () from /lib/tls/i686/cmov/libc.so.6
#5  0xb7d639c5 in malloc () from /lib/tls/i686/cmov/libc.so.6
#6  0xb7f42f47 in operator new () from /usr/lib/libstdc++.so.6
#7  0x0805bd20 in Image<Color>::fft (this=0xb467640) at ../image_processing/image.cpp:545

Que se passe-t-il ici? L'opérateur new se bloque, ok. Mais pourquoi? Ce n'est pas un manque de mémoire (il essaie d'allouer environ 128 Ko, un pixel de 128x64 avec deux flottants chacun). En outre, cela ne ressemble pas à une erreur car c'est une erreur dans mon propre code (le constructeur n'est pas touché!).

Le code dans la ligne mentionnée (n ° 7) est:

Image<Complex> *result = new Image<Complex>(this->resX, resY); 
// this->resX = 128, resY = 64 (both int), Complex is a typedef for std::complex<float>

Presque la même instanciation fonctionne à d’autres endroits de mon code. Si je commente cette partie du code, elle se plantera un peu plus tard sur une partie similaire. Je ne le comprends pas, je n'ai pas non plus d'idées, comment le déboguer. Toute aide?

Le compilateur est gcc 4.3.3, la libc est 2.9 (les deux de Ubuntu Jaunty)

Mise à jour:

J'ai inclus les lignes suivantes juste au-dessus de la ligne défectueuse dans la même méthode et dans main ()

    Image<Complex> *test = new Image<Complex>(128, 64);
    delete test;

La chose étrange: dans la même méthode, il va planter, dans main () ça ne va pas. Comme je l'ai mentionné, Complex est un typedef de std :: complex & Lt; float & Gt ;. Le constructeur ne s'appelle pas, j'ai inséré un cout juste avant cette ligne et dans le constructeur lui-même.

Mise à jour 2:

Merci à KPexEA pour ce conseil! J'ai essayé ceci:

Image<Complex> *test = new Image<Complex>(128, 64);
delete test;

kiss_fft_cpx *output = (kiss_fft_cpx*) malloc( this->resX * this->resY/2 * sizeof(kiss_fft_cpx) );
kiss_fftndr( cfg, input, output );

Image<Complex> *test2 = new Image<Complex>(128, 64);
delete test2;

Il se bloque à - vous devinez? - test2! Donc, le malloc pour mon kissfft semble être le défectueux. Je vais y jeter un coup d'œil.

Mise à jour finale:

Ok, c'est fait! Merci à tous!

En fait, j'aurais dû le remarquer avant. La semaine dernière, j’ai remarqué que kissfft (une bibliothèque de transformation rapide de Fourier) produisait une image fft de 130 x 64 pixels à partir d’une image source de 128 x 128 pixels. Oui, 130 pixels de large, pas 128. Ne me demandez pas pourquoi, je ne sais pas! Donc, il fallait allouer 130x64x2xsizeof (float) octets, et non pas 128x64x ... comme je le pensais auparavant. Étrange, il ne s'est pas écrasé juste après que j'ai corrigé ce bogue, mais quelques jours plus tard.

Pour mémoire, mon code final est le suivant:

int resY = (int) ceil(this->resY/2);

kiss_fft_cpx *output = (kiss_fft_cpx*) malloc( (this->resX+2) * resY * sizeof(kiss_fft_cpx) );
kiss_fftndr( cfg, input, output );

Image<Complex> *result = new Image<Complex>(this->resX, resY);

Merci!

craesh

Answer 1

Peut-être qu'un bloc de mémoire alloué précédemment a un débordement de mémoire tampon qui endommage le tas?

Answer 2

Vous n'allouez pas assez de mémoire. Le format à demi-spectre de kissfft (ainsi que FFTW et IMKL) contient des éléments complexes X * (Y / 2 + 1).

Voir le fichier d'en-tête kiss_fftndr.h:

/ *  le temps d'entrée a dims [0] x dims [1] X ... X dims [ndims-1] points scalaires

la sortie freqdata a dims [0] X dims [1] X ... X dims [ndims-1] / 2 + 1 points complexes *