Вызов функций из функции (float *VeryBigArray,long SizeofArray) из метода objC завершается с ошибкой EXC_BAD_ACCESS

Question

Хорошо, я наконец нашел проблему.Это было внутри функции C (CarbonTuner2), а не метода objC.Я создавал внутри функции массив того же размера, что и размер файла, поэтому, если размер файла был большим, создавался действительно большой массив, и я предполагаю, что когда я вызывал оттуда другую функцию, локальные переменные помещались в стек, что создал EXC_BAD_ACCESS.Тогда я сделал следующее: вместо того, чтобы использовать переменную для объявления размера массива, я указал число напрямую.Тогда код даже не компилировался.оно знало.Ошибка была примерно такая:Размер массива слишком велик.Я думаю, работать более 20 часов подряд — это нехорошо XD Но я определенно собираюсь изучить другие инструменты, кроме пошаговой отладки, чтобы разобраться в них.Спасибо за вашу помощь.Вот код.Если вы разделите gFileByteCount на 2, вы больше не получите ошибку:

//  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

Ваш сбой не имеет ничего общего с несовместимостью между C и ObjC.И, как говорилось в предыдущих постах, вам не нужно включать math.h.

Запустите свой код под GDB и посмотрите, где происходит сбой, используя обратную трассировку.

Вы уверены, что не отправляете неверные аргументы математическим функциям?

Например.это вызывает BAD_ACCESS:двойной т = потому что (*(двойной *)NULL);

Answer 2

Objective C построен непосредственно на C, и основы C могут работать и работают.

Пример использования math.h и частей стандартной библиотеки из модуля Objective C см. в разделе:

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

Есть и другие примеры.

Требуется некоторая осторожность при передаче переменных;используйте переменные C для вызовов C и стандартной библиотеки;не смешивайте неосторожно типы данных C и типы данных Objective C.Обычно вам понадобится конверсия здесь.

Если это не так, рассмотрите возможность публикации используемого кода и ошибок, которые вы получаете.

И, при всем уважении к ответу г-на Хеллмана, у меня возникали ошибки, когда у меня не были включены файлы заголовков;Я предпочитаю включать заголовки.Но с другой стороны, я также склонен повысить диагностику компилятора на пару ступеней.

Answer 3

Как бы то ни было, я не включаю math.h в свое приложение Cocoa, но у меня нет проблем с использованием математических функций (в C).

Например, я использую atan() и не получаю ошибок компилятора или ошибок времени выполнения.

Можете ли вы попробовать это, вообще не включая math.h?

Answer 4

Во-первых, вам следует добавить свой код к своему вопросу, а не публиковать его как ответ, чтобы люди могли видеть, о чем вы спрашиваете.Во-вторых, здесь возникают всевозможные странные проблемы с управлением памятью — gFileByteCount используется для определения размера группы буферов, но он установлен на ноль и, похоже, нигде не переустанавливается.

err = audioFileReadpackets (fileId, false, & bytesturned, null, 0, & packets, (byte *) rawaudio);

Итак, на этом этапе вы передаете буфер нулевого размера в AudioFileReadPackets, который быстро переполняет кучу, искажая значение неизвестно каких других переменных...

frawaudio = malloc (gfilebytecount/(биты/8)*sizeof (frawaudio));

Вот еще одна незначительная ошибка: здесь вам нужен sizeof(*fRawAudio), поскольку вы пытаетесь выделить массив чисел с плавающей запятой, а не массив указателей с плавающей запятой.К счастью, эти объекты имеют одинаковый размер, так что это не имеет значения.

Вероятно, вам следует начать с примера кода, который, как вы знаете, работает (SpeakHere?), и изменить его.Я подозреваю, что в опубликованном вами коде есть и другие подобные проблемы, но сейчас у меня нет времени их искать.По крайней мере, получите буфер rawAudio соответствующего размера и соответствующим образом используйте значения, возвращаемые из AudioFileReadPackets.