Rastreo extraño: ¿dónde está el error?

Question

Estoy desarrollando una aplicación de procesamiento de imágenes en C ++. He visto muchos errores y retrocesos del compilador, pero este es nuevo para mí.

#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

¿Qué está pasando aquí? El operador nuevo se está bloqueando, está bien. ¿Pero por qué? Eso no es falta de memoria (intenta asignar aproximadamente 128 Kb, un píxel de 128x64 con dos flotantes cada uno). Además, no parece ser un error en mi propio código (¡el constructor no se toca!).

El código en la línea mencionada (# 7) es:

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

Casi la misma instancia funciona en otros lugares en mi código. Si comento esta parte del código, se bloqueará un poco más tarde en una parte similar. No lo entiendo, tampoco tengo ideas sobre cómo depurarlo. ¿Alguna ayuda?

El compilador es gcc 4.3.3, libc es 2.9 (ambos de Ubuntu Jaunty)

Update:

He incluido las siguientes líneas justo encima de la línea defectuosa en el mismo método y en main ()

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

Lo extraño: en el mismo método se bloqueará, en main () no lo hará. Como mencioné, Complex es un typedef de std :: complex & Lt; float & Gt ;. No se llama al constructor, he insertado un cout justo antes de esta línea y en el propio constructor.

Actualización 2:

¡Gracias a KPexEA por este consejo! Intenté esto:

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;

Se estrella en - ¿adivinas? - test2! Así que el malloc para mi beso parece ser el defectuoso. Lo echaré un vistazo.

Actualización final:

Ok, ¡está hecho! ¡Gracias a todos ustedes!

En realidad, debería haberlo notado antes. La semana pasada, noté, que kissfft (una biblioteca rápida de transformadas de Fourier) hizo una imagen de 130x64 píxeles fft a partir de una imagen fuente de 128x128 píxeles. Sí, 130 píxeles de ancho, no 128. ¡No me pregunten por qué, no lo sé! Entonces, 130x64x2xsizeof (flotante) bytes tuvieron que ser asignados, no 128x64x ... como pensaba antes. Extraño, que no se bloqueó justo después de que solucioné ese error, pero algunos días después.

Para el registro, mi código final es:

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

¡Gracias!

craesh

Answer 1

¿Quizás una porción de memoria previamente asignada tiene un desbordamiento de búfer que está corrompiendo el montón?

Answer 2

No está asignando suficiente memoria. El formato de medio espectro de kissfft (y FFTW e IMKL) contiene elementos complejos X * (Y / 2 + 1).

Ver el archivo de encabezado kiss_fftndr.h:

/ *  input timedata tiene dims [0] X dims [1] X ... X dims [ndims-1] puntos escalares

la salida freqdata tiene dims [0] X dims [1] X ... X dims [ndims-1] / 2 + 1 puntos complejos *