Я разрабатываю приложение для обработки изображений на C++. Я видел много ошибок компилятора и backtraces, но это ново для меня.Странный backtrace - где ошибка?
#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
Что здесь происходит? Новый оператор сбой, нормально. Но почему? Это не из памяти (он пытается выделить около 128Kb, 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)
Обновление:
Я включил следующие строки непосредственно над поврежденной линии в том же способом и в основной()
Image<Complex> *test = new Image<Complex>(128, 64);
delete test;
странная вещь: в тот же метод он будет врезаться в основной() не будет. Как я уже упоминал, Complex представляет собой typedef std :: complex <float>. Конструктор не вызван, я вставил cout прямо перед этой строкой и в самом конструкторе.
Update 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 (быстрая библиотека преобразований Фурье) сделал изображение размером в 130 x 64 пикселя из исходного изображения с разрешением 128x128 пикселей. Да, 130 пикселей широкий, а не 128. Не спрашивайте меня, почему, я не знаю! Таким образом, должны были быть выделены байты размером 130x64x2xsizeof (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
Возможно, добавьте пример «почти того же» экземпляра, который работает? – Amber