Я занимаюсь разработкой приложения для обработки изображений на C ++. Я видел много ошибок компиляции и следов, но этот является новым для меня.
#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
Что здесь происходит? Оператор новый сбой, хорошо. Но почему? Это не нехватка памяти (он пытается выделить около 128 КБ, 128x64 пикселей с двумя числами с плавающей запятой каждый). Кроме того, это не шов, поскольку это ошибка в моем собственном коде (конструктор не трогается!).
Код в указанной строке (# 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>
Практически такая же реализация работает в других местах моего кода. Если я закомментирую эту часть кода, он чуть позже потерпит крах в аналогичной части. Я этого не понимаю, у меня тоже нет идей, как это отладить. Любая помощь?
Компилятор gcc 4.3.3, libc 2.9 (оба из Ubuntu Jaunty)
Обновление:
Я включил следующие строки прямо над ошибочной строкой в том же методе и в main ()
Image<Complex> *test = new Image<Complex>(128, 64);
delete test;
Странная вещь: в том же методе он потерпит крах, в main () - нет. Как я уже упоминал, Complex является typedef для std :: complex . Конструктор не вызывается, я вставил cout перед этой строкой и в самом конструкторе.
Обновление 2:
Спасибо KPexEA за этот совет! Я попробовал это:
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;
Это сбой при ... вы догадываетесь? - test2! Таким образом, malloc для моих швов Kissfft будет неисправным. Я посмотрю на это.
Окончательное обновление:
Хорошо, все готово! Всем спасибо!
На самом деле, я должен был заметить это раньше. На прошлой неделе я заметил, что kissfft (библиотека быстрого преобразования Фурье) создала изображение fft размером 130x64 пикселей из исходного изображения 128x128 пикселей. Да, 130 пикселей в ширину, а не 128. Не спрашивайте меня, почему, я не знаю! Итак, 130x64x2xsize (float) байтов должны были быть выделены, а не 128x64x ... как я думал раньше. Странно, что это произошло не сразу после того, как я исправил эту ошибку, а через несколько дней.
Для записи мой окончательный код:
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);
Спасибо!
craesh