奇怪的回溯 - 错误在哪里?

发布于 2024-07-30 08:22:52 字数 2466 浏览 3 评论 0原文

我正在用 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

这里发生了什么事? new 操作符崩溃了,好吧。 但为什么? 这并不是内存不足(它尝试分配大约 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)

更新:

我在相同的方法和 main() 中的错误行上方包含了以下几行

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

奇怪的事情:在同样的方法中它会崩溃,在 main() 中它不会。 正如我所提到的,Complex 是 std::complex的 typedef。 构造函数不会被调用,我在该行之前和构造函数本身中插入了一个 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;

它崩溃了 - 你猜? - 测试2! 所以我的 Kissfft 的 malloc 似乎是有问题的。 我会看一下。

最终更新:

好的,完成了! 感谢大家!

其实我早该注意到的。 上周,我注意到 Kissfft(一个快速傅里叶变换库)从 128x128 像素源图像生成了 130x64 像素 FFT 图像。 是的,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);

谢谢!

克雷什

I'm developing an image processing application in C++. I've seen a lot of compiler errors and backtraces, but this one is new to me.

#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

What's happening here? The operator new is crashing, ok. But why? That's not an out of memory (it tries to allocate about 128Kb, a 128x64 pixel with two floats each). Also, it doesn't seam as it's an error in my own code (the constructor doesn't get touched!).

The code in the mentioned line (#7) is:

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

Almost the same instantiation works on other places in my code. If I comment out this part of the code, it will crash a bit later on a similar part. I don't understand it, I also don't have any ideas, how to debug it. Any help?

Compiler is gcc 4.3.3, libc is 2.9 (both from Ubuntu Jaunty)

Update:

I've included the following lines just above the faulty line in the same method and in main()

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

The strange thing: in the same method it will crash, in main() it won't. As I mentioned, Complex is a typedef of std::complex<float>. The constructor doesn't get called, I've inserted a cout just before this line and in the constructor itself.

Update 2:

Thanks to KPexEA for this tip! I tried this:

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;

It crashes at - you guess? - test2! So the malloc for my kissfft seams to be the faulty one. I'll take a look at it.

Final update:

Ok, it's done! Thanks to all of you!

Actually, I should have noticed it before. Last week, I noticed, that kissfft (a fast fourier transform library) made a 130x64 pixel fft image from a 128x128 pixel source image. Yes, 130 pixel broad, not 128. Don't ask me why, I don't know! So, 130x64x2xsizeof(float) bytes had to be allocated, not 128x64x... as I thought before. Strange, that it didn't crash just after I fixed that bug, but some days later.

For the record, my final code is:

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

Thanks!

craesh

如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。

扫码二维码加入Web技术交流群

发布评论

需要 登录 才能够评论, 你可以免费 注册 一个本站的账号。

评论(2

爱你是孤单的心事 2024-08-06 08:22:52

也许先前分配的内存块存在缓冲区溢出,从而损坏了堆?

Perhaps a previously allocated chunk of memory has a buffer overflow that is corrupting the heap?

舂唻埖巳落 2024-08-06 08:22:52

您没有分配足够的内存。 Kissfft 的半谱格式(以及 FFTW 和 IMKL)包含 X*(Y/2+1) 复杂元素。

参见kiss_fftndr.h头文件:

/*
输入 timedata 具有 dims[0] X dims[1] X ... X dims[ndims-1] 标量点

输出 freqdata 具有 dims[0] X dims[1] X ... X dims[ndims-1]/2 +1 复杂点
*

You are not allocating enough memory. The half-spectrum format of kissfft (and FFTW and IMKL for that matter) contains X*(Y/2+1) complex elements.

See the kiss_fftndr.h header file:

/*
input timedata has dims[0] X dims[1] X ... X dims[ndims-1] scalar points

output freqdata has dims[0] X dims[1] X ... X dims[ndims-1]/2+1 complex points
*

~没有更多了~
我们使用 Cookies 和其他技术来定制您的体验包括您的登录状态等。通过阅读我们的 隐私政策 了解更多相关信息。 单击 接受 或继续使用网站,即表示您同意使用 Cookies 和您的相关数据。
原文