Вызов функций из функции (float *VeryBigArray,long SizeofArray) из метода objC завершается с ошибкой EXC_BAD_ACCESS
-
21-08-2019 - |
Вопрос
Хорошо, я наконец нашел проблему.Это было внутри функции 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);
}
Решение
Ваш сбой не имеет ничего общего с несовместимостью между C и ObjC.И, как говорилось в предыдущих постах, вам не нужно включать math.h.
Запустите свой код под GDB и посмотрите, где происходит сбой, используя обратную трассировку.
Вы уверены, что не отправляете неверные аргументы математическим функциям?
Например.это вызывает BAD_ACCESS:двойной т = потому что (*(двойной *)NULL);
Другие советы
Objective C построен непосредственно на C, и основы C могут работать и работают.
Пример использования math.h и частей стандартной библиотеки из модуля Objective C см. в разделе:
http://en.wikibooks.org/wiki/Objective-C_Programming/syntax
Есть и другие примеры.
Требуется некоторая осторожность при передаче переменных;используйте переменные C для вызовов C и стандартной библиотеки;не смешивайте неосторожно типы данных C и типы данных Objective C.Обычно вам понадобится конверсия здесь.
Если это не так, рассмотрите возможность публикации используемого кода и ошибок, которые вы получаете.
И, при всем уважении к ответу г-на Хеллмана, у меня возникали ошибки, когда у меня не были включены файлы заголовков;Я предпочитаю включать заголовки.Но с другой стороны, я также склонен повысить диагностику компилятора на пару ступеней.
Как бы то ни было, я не включаю math.h в свое приложение Cocoa, но у меня нет проблем с использованием математических функций (в C).
Например, я использую atan() и не получаю ошибок компилятора или ошибок времени выполнения.
Можете ли вы попробовать это, вообще не включая math.h?
Во-первых, вам следует добавить свой код к своему вопросу, а не публиковать его как ответ, чтобы люди могли видеть, о чем вы спрашиваете.Во-вторых, здесь возникают всевозможные странные проблемы с управлением памятью — gFileByteCount используется для определения размера группы буферов, но он установлен на ноль и, похоже, нигде не переустанавливается.
err = audioFileReadpackets (fileId, false, & bytesturned, null, 0, & packets, (byte *) rawaudio);
Итак, на этом этапе вы передаете буфер нулевого размера в AudioFileReadPackets, который быстро переполняет кучу, искажая значение неизвестно каких других переменных...
frawaudio = malloc (gfilebytecount/(биты/8)*sizeof (frawaudio));
Вот еще одна незначительная ошибка: здесь вам нужен sizeof(*fRawAudio), поскольку вы пытаетесь выделить массив чисел с плавающей запятой, а не массив указателей с плавающей запятой.К счастью, эти объекты имеют одинаковый размер, так что это не имеет значения.
Вероятно, вам следует начать с примера кода, который, как вы знаете, работает (SpeakHere?), и изменить его.Я подозреваю, что в опубликованном вами коде есть и другие подобные проблемы, но сейчас у меня нет времени их искать.По крайней мере, получите буфер rawAudio соответствующего размера и соответствующим образом используйте значения, возвращаемые из AudioFileReadPackets.