Calling functions from within function(float *VeryBigArray,long SizeofArray) from within objC method fails with EXC_BAD_ACCESS

Question

Ok I finally found the problem. It was inside the C function(CarbonTuner2) not the objC method. I was creating inside the function an array of the same size as the file size so if the filesize was big it created a really big array and my guess is that when I called another function from there, the local variables were put on the stack which created the EXC_BAD_ACCESS. What I did then is instead of using a variable to declare to size of the array I put the number directly. Then the code didnt even compile. it knew. The error wassomething like: Array size too big. I guess working 20+hours in a row isnt good XD But I am definitly gonna look into tools other than step by step debuggin to figure these ones out. Thanks for your help. Here is the code. If you divide gFileByteCount by 2 you dont get the error anymore:

//  ConverterController.h

# import <Cocoa/Cocoa.h>
# import "Converter.h"

@interface ConverterController : NSObject {

    UInt64 gFileByteCount ;
}

-(IBAction)ProcessFile:(id)sender;
void CarbonTuner2(long numSampsToProcess, long fftFrameSize, long osamp);

@end

//  ConverterController.m
# include "ConverterController.h"

@implementation ConverterController

-(IBAction)ProcessFile:(id)sender{

    UInt32 packets = gTotalPacketCount;//alloc a buffer of memory to hold the data read from disk.

    gFileByteCount=250000;
    long LENGTH=(long)gFileByteCount;
    CarbonTuner2(LENGTH,(long)8192/2, (long)4*2);
}
@end

void CarbonTuner2(long numSampsToProcess, long fftFrameSize, long osamp)
{
    long numFrames = numSampsToProcess / fftFrameSize * osamp;
    float g2DFFTworksp[numFrames+2][2 * fftFrameSize];
    double hello=sin(2.345);
}

Answer 1

Your crash has nothing to do with incompatibilities between C and ObjC. And as previous posters said, you don't need to include math.h.

Run your code under gdb, and see where the crash happens by using backtrace.

Are you sure you're not sending bad arguments to the math functions?

E.g. this causes BAD_ACCESS: double t = cos(*(double *)NULL);

Answer 2

Objective C is built directly on C, and the C underpinnings can and do work.

For an example of using math.h and parts of standard library from within an Objective C module, see:

http://en.wikibooks.org/wiki/Objective-C_Programming/syntax

There are other examples around.

Some care is needed around passing the variables around; use the C variables for the C and standard library calls; don't mix the C data types and Objective C data types incautiously. You'll usually want a conversion here.

If that is not the case, then please consider posting the code involved, and the error(s) you are receiving.

And with all respect due to Mr Hellman's response, I've hit errors when I don't have the header files included; I prefer to include the headers. But then, I tend to dial the compiler diagnostics up a couple of notches, too.

Answer 3

For what it's worth, I don't include math.h in my Cocoa app but have no problem using math functions (in C).

For example, I use atan() and don't get compiler errors, or run time errors.

Can you try this without including math.h at all?

Answer 4

First, you should add your code to your question, rather than posting it as an answer, so people can see what you're asking about. Second, you've got all sorts of weird problems with your memory management here - gFileByteCount is used to size a bunch of buffers, but it's set to zero, and doesn't appear to get re-set anywhere.

err = AudioFileReadPackets (fileID, false, &bytesReturned, NULL,0, &packets,(Byte *)rawAudio);

So, at this point, you pass a zero-sized buffer to AudioFileReadPackets, which prompty overruns the heap, corrupting the value of who knows what other variables...

fRawAudio = malloc(gFileByteCount/(BITS/8)*sizeof(fRawAudio));

Here's another, minor error - you want sizeof(*fRawAudio) here, since you're trying to allocate an array of floats, not an array of float pointers. Fortunately, those entities are the same size, so it doesn't matter.

You should probably start with some example code that you know works (SpeakHere?), and modify it. I suspect there are other similar problems in the code yoou posted, but I don't have time to find them right now. At least get the rawAudio buffer appropriately-sized and use the values returned from AudioFileReadPackets appropriately.