Question

Sorry for the many posts here regarding this issue but i am having a progress here.

I have a callback function, which is in C , and been called when a new buffer is arrived.

I was told here to not do ANYTHING in that callback ,not malloc , or anything .

Now i want to send my new buffer to another class( which will create a circle buffer and save many buffers).

BUT, the basic thing that i dont get, is that if i call another function from the callback - its the same as doing it in there- becuase in that function i do the DSP and it takes time, so its the same as doing it in that callback- because its in serial.

froof : i am sending the data to another function in another class, and its ok, but if i try to NSLOG it in there, i AGAIN have this memory leaks.

here is the other class that i call from the callback :

    - (id)init 
    {
        self = [super init];
        if (self)

        {
            data = malloc (sizeof(SInt16) * 4000);


        }
        return self;
    }

 -(void)sendNewBuffer:(SInt16*)buffer
    {

        data=buffer;

        NSLog(@"data arrived size is : %lu",sizeof(data));
        for(int i=0; i<sizeof(data);i++)
        {
            NSLog(@"%d",data[i]);
        }

    }

ONLY when comment the log, it works without memory leaks. that means the callback is waiting for that !

How would i process that data somwhere else in parallel ? i am spending a week for that now.

thanks.

Was it helpful?

Solution

One possibility for the memory leak when using Objective-C objects such as the NSString in the NSLog is that those objects may be autoreleased (or may internally used autoreleased objects).

Your callback may be called from a different thread. You can confirm this by putting a breakpoint in the callback and looking in the debugger if this is the main thread or a secondary thread.

Any secondary thread must have its own AutoRelease pool. The system creates one automatically for the main thread, but you must create one explicitly if you are to create a secondary thread.

Also, one reason for not allocating stuff in a callback is usually for performances. Often the callback needs to be kept at minimum to avoid blocking the thread that called it.

OTHER TIPS

I would suggest you read a C tutorial. There are at least two problems with your code which we can't really help you with:

  • data=buffer;: this leaks the previous value of data. You need to copy it to data (memcpy) or release the memory first (free) and then keep the pointer... unless the buffer goes out of scope after the callback, in which case your only option is to copy
  • sizeof(data): this can't work. data is a pointer; it doesn't know the amount of data that it being pointed at

The second means that you can't correctly implement the call back, at least not without further information. (Either the buffer has some indication of the volume of data or it's a constant size.)

If I had to guess (and I suppose I do) the callback is probably called in an interrupt context, hence malloc etc. would possibly be fatal. What I would do is copy (ie. memcpy) the data to a buffer, and schedule/signal handling code to run later (eg. using condition variables, a runloop source, etc.)

Licensed under: CC-BY-SA with attribution
Not affiliated with StackOverflow
scroll top