tags:

views:

267

answers:

2

Hi!

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

+4  A: 

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

KPexEA
I definitely see this type of random error when an access out of bounds is done, check the rest of your code, remember you can access out of bounds with no immediate error, it just hides and randomly pops up in malloc/free new/delete calls. One of the most frustrating bugs to track I find.
DeusAduro
A: 

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 *

Mark Borgerding