Chiamando funzioni dalla funzione (float * VeryBigArray, lungo SizeofArray) dall'interno metodo objc riesce con EXC_BAD_ACCESS

Question

Ok ho finalmente trovato il problema. Era all'interno della funzione C (CarbonTuner2) non il metodo objc. Stavo creando all'interno della funzione una matrice delle stesse dimensioni, come le dimensioni del file, quindi se la dimensione del file è stato grande ha creato davvero un grande array e la mia ipotesi è che quando ho chiamato un'altra funzione da lì, le variabili locali sono state messe in pila, che ha creato l'EXC_BAD_ACCESS. Quello che ho fatto allora è invece di utilizzare una variabile di dichiarare alla dimensione dell'array ho messo direttamente il numero. Quindi il codice non ha ancora nemmeno compilare. sapeva. L'errore wassomething piace: dimensione Array troppo grande. Credo che lavorando 20 + ore di fila non sta bene XD Ma sono sicuramente andando sguardo in strumenti diversi dal passo dopo passo debuggin per capire questi fuori. Grazie per l'aiuto. Ecco il codice. Se si divide gFileByteCount da 2 non si ottengono più l'errore:

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

Il tuo incidente non ha nulla a che fare con le incompatibilità tra C e objC. E, come detto nelle precedenti revisioni, non è necessario includere math.h.

eseguire il codice sotto gdb, e vedere dove l'incidente avviene utilizzando backtrace.

Sei sicuro che non stai inviando cattivi argomenti per le funzioni matematiche?

es. questo fa sì che BAD_ACCESS:     doppie t = cos (* (doppia *) NULL);

Answer 2

Objective C è costruito direttamente su C, e le basi C può e fare il lavoro.

Per un esempio di utilizzo math.h e parti di libreria standard all'interno di un modulo di Objective C, vedi:

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

Ci sono altri esempi in giro.

Alcuni attenzione è necessaria in giro passando le variabili intorno; utilizzare le variabili C per le chiamate di libreria standard C e; non mischiare i tipi di dati C e tipi di dati C Obiettivo incautamente. Ti solito si desidera una conversione qui.

Se questo non è il caso, allora perche non inviare il codice in questione, e l'errore (s) che si ricevono.

E con tutto il rispetto dovuto alla risposta del signor Hellman, ho colpito errori quando non ho i file di intestazione inclusi; Io preferisco di includere le intestazioni. Ma poi, tendo a chiamare la diagnostica del compilatore di un paio di tacche, anche.

Answer 3

Per quel che vale, io non includere math.h nel mio cacao app, ma non hanno alcun problema utilizzando funzioni matematiche (in C).

Per esempio, io uso atan () e non si ottiene errori di compilazione, o eseguire gli errori di tempo.

Si può provare questo senza includere math.h a tutti?

Answer 4

In primo luogo, si dovrebbe aggiungere il codice alla tua domanda, piuttosto che la pubblicazione come una risposta, così la gente può vedere quello che stai chiedendo circa. In secondo luogo, hai tutti i tipi di problemi strani con la gestione della memoria qui -. GFileByteCount viene utilizzato per dimensioni un po 'di buffer, ma è impostato a zero, e non sembra per ottenere ri-set ovunque

  

err = AudioFileReadPackets (fileid,   falso, e bytesReturned, NULL, 0,   & Pacchetti, (Byte *) rawaudio);

Quindi, a questo punto, si passa un buffer di dimensioni zero a AudioFileReadPackets, che invade prontamente mucchio, corrompendo il valore di chissà quali altre variabili ...

  

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

Ecco un altro, piccolo errore - si vuole sizeof (* fRawAudio) qui, dal momento che si sta cercando di allocare una matrice di carri, non un array di puntatori galleggiante. Fortunatamente, queste entità sono le stesse dimensioni, quindi non importa.

Probabilmente si dovrebbe cominciare con qualche esempio di codice che si sa opere (SpeakHere?), E modificarlo. Ho il sospetto che ci sono altri problemi simili nel codice yoou postato, ma non ho tempo per trovare loro in questo momento. Almeno avere buffer rawaudio dimensioni appropriate e utilizzare i valori restituiti da AudioFileReadPackets appropriato.