backtrace estranho - onde está o erro?

Question

Estou desenvolvendo uma aplicação de processamento de imagem em C ++. Eu vi um monte de erros do compilador e backtraces, mas este é novo para mim.

#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

O que está acontecendo aqui? O novo operador está falhando, ok. Mas por que? Isso não é uma falta de memória (ele tenta alocar cerca de 128Kb, um pixel 128x64 com dois carros alegóricos cada). Além disso, ele não costura como é um erro no meu próprio código (o construtor não se tocado!).

O código no mencionado linha (# 7) é:

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

Quase as mesmas obras instanciação em outros lugares no meu código. Se eu comentar esta parte do código, ele irá travar um pouco mais tarde em uma peça similar. Eu não entendo isso, eu também não tem quaisquer ideias, como depurá-lo. Qualquer ajuda?

Compiler é gcc 4.3.3, libc é 2.9 (ambos a partir do Ubuntu Jaunty)

Update:

Eu incluí as seguintes linhas logo acima da linha defeituosa no mesmo método e no main ()

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

O estranho: no mesmo método que irá falhar, em main () não vai. Como eu mencionei, Complex é um typedef de std :: complex . O construtor não se ligou, eu tenho inserido um cout pouco antes desta linha e no próprio construtor.

Update 2:

Graças à KPexEA para esta dica! Eu tentei isso:

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;

Ele trava na - você adivinhou? - test2! Assim, o malloc para as minhas costuras kissfft ser o único defeito. Vou dar uma olhada nisso.

atualização final:

Ok, está feito! Graças a todos vocês!

Na verdade, eu deveria ter percebido antes. Na semana passada, eu notei, que kissfft (uma biblioteca rápida Transformada de Fourier) feita da FFT uma 130x64 pixels de imagem de origem a 128x128 pixel. Sim, 130 pixels ampla, e não 128. Não me pergunte por que, eu não sei! Então, 130x64x2xsizeof (float) bytes teve que ser alocado, não 128x64x ... como eu pensava antes. Estranho, que não caiu logo após eu fixo que bug, mas alguns dias depois.

Para o registro, o meu código final é:

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);

Obrigado!

craesh

Answer 1

Talvez um pedaço previamente alocado de memória tem um buffer overflow que está corrompendo a pilha?

Answer 2

Você não está alocando memória suficiente. O formato de meia-espectro de kissfft (e FFTW e IMKL para esse efeito) contém X * (Y / 2 + 1) elementos complexos.

Veja o arquivo de cabeçalho kiss_fftndr.h:

/ * TimeData entrada tem escurece [0] X escurece [1] X ... X escurece [ndims-1] pontos escalares

freqdata saída tem escurece [0] X escurece [1] x ... x escurece [ndims-1] / 2 + 1 pontos complexos *