Chamando funções na função (flutuador * VeryBigArray, longo SizeofArray) de dentro do método ObjC falha com EXC_BAD_ACCESS

Question

Ok eu finalmente encontrei o problema. Foi dentro da função C (CarbonTuner2) não o método ObjC. Eu estava criando dentro da função uma matriz do mesmo tamanho que o tamanho do arquivo por isso, se o tamanho do arquivo foi grande que criou um realmente grande variedade e meu palpite é que quando liguei outra função a partir daí, as variáveis ??locais foram colocados na pilha que criou o EXC_BAD_ACCESS. O que eu fiz, então, é em vez de usar uma variável para declarar ao tamanho da matriz eu coloquei o número diretamente. Em seguida, a não funcionavam código sequer compilar. ele sabia. O wassomething erro como: tamanho de matriz muito grande. Eu acho que trabalhar 20 + horas em um bom XD fileira is not Mas estou definitivamente vai olhar para outros do que passo a passo debuggin para descobrir estes queridos para fora ferramentas. Obrigado pela ajuda. Aqui está o código. Se você dividir gFileByteCount por 2 você não obter o erro mais:

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

O acidente não tem nada a ver com incompatibilidades entre C e ObjC. E, como cartazes anteriores disse, você não precisa incluir math.h.

Executar o seu código sob gdb, e ver onde o acidente acontece usando backtrace.

Tem certeza de que não estamos enviando maus argumentos para as funções matemáticas?

por exemplo. isso faz com que BAD_ACCESS: duplo t = cos (* (* dupla) NULL);

Answer 2

Objective C é construído diretamente no C, e as bases C pode e fazer o trabalho.

Para um exemplo da utilização e partes de math.h biblioteca padrão a partir de dentro de um módulo C Objectivo, ver:

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

Há outros exemplos ao redor.

Alguns cuidados são necessários em torno de passar as variáveis ??ao redor; usar as variáveis ??C para o C e chamadas de biblioteca padrão; não misturar os tipos de dados C e tipos de dados C Objectivo incautiously. Você geralmente deseja uma conversão aqui.

Se isso não for o caso, então por favor considere postar o código envolvido, e o erro (s) que você está recebendo.

E com todo o respeito devido à resposta do Sr. Hellman, eu bati erros quando eu não tenho os arquivos de cabeçalho incluído; Eu prefiro para incluir os cabeçalhos. Mas então, eu tendem a marcar os diagnósticos de compilador-se um par de entalhes, também.

Answer 3

Por que vale a pena, eu não incluem math.h em meu aplicativo de cacau, mas não tenho nenhum problema usando funções matemáticas (em C).

Por exemplo, eu uso atan () e não obter erros de compilador, ou erros de tempo de execução.

Você pode tentar isso sem incluir math.h em tudo?

Answer 4

Primeiro, você deve adicionar o código à sua pergunta, em vez de publicá-la como uma resposta, que as pessoas possam ver o que você está perguntando sobre. Em segundo lugar, você tem todos os tipos de problemas estranhos com o seu gerenciamento de memória aqui -. GFileByteCount é usado para dimensionar um monte de buffers, mas ele é definido como zero, e não parece chegar a qualquer lugar re-set

err = AudioFileReadPackets (FileID, falsa, e bytesReturned, NULL, 0, & Pacotes, (Byte *) rawAudio);

Assim, neste ponto, você passar um buffer de tamanho zero para AudioFileReadPackets, que prompty derrapagens pilha, corrompendo o valor de quem sabe o que outras variáveis ??...

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

Aqui está um outro, menor erro - você quer sizeof (* fRawAudio) aqui, já que você está tentando alocar uma matriz de carros alegóricos, e não uma matriz de ponteiros de flutuação. Felizmente, essas entidades são do mesmo tamanho, por isso não importa.

Você provavelmente deve começar com algum exemplo de código que você sabe que funciona (SpeakHere?), E modificá-lo. Eu suspeito que há outros problemas semelhantes no código yoou postado, mas eu não tenho tempo para encontrá-los agora. Pelo menos obter tampão de dimensão adequada a rawAudio e utilizar os valores devolvidos a partir AudioFileReadPackets apropriadamente.