Llamar a las funciones dentro de la función (float * VeryBigArray, a largo SizeofArray) desde dentro ObjC método falla con EXC_BAD_ACCESS

Question

Ok finalmente encontré el problema. Fue dentro de la función C (CarbonTuner2) no el método ObjC. Estaba creando dentro de la función una matriz del mismo tamaño que el tamaño del archivo de modo que si el tamaño del archivo fue grande que creó una muy grande variedad y mi conjetura es que cuando me llamó otra función a partir de ahí, las variables locales se pusieron en la pila, que creó el EXC_BAD_ACCESS. Lo que hice entonces en lugar de utilizar una variable para declarar al tamaño de la matriz puse directamente el número. A continuación, el código ni tan siquiera compilar. conoció. El error wassomething como: Tamaño de la matriz demasiado grande. Supongo que trabajar 20 o más horas en una fila isnt buena XD Pero estoy definitivamente va a buscar en otro tipo de herramientas paso a paso debuggin de entender estos unos hacia fuera. Gracias por tu ayuda. Aquí está el código. Si se divide por 2 gFileByteCount usted no recibe el error más:

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

Su accidente no tiene nada que ver con las incompatibilidades entre C y ObjC. Y como dijeron los críticos anteriores, no es necesario incluir math.h.

Ejecutar el código bajo el BGF, y vea donde el accidente ocurre mediante el uso de traza.

¿Estás seguro de que no va a enviar malos argumentos a las funciones matemáticas?

por ejemplo. esto hace que BAD_ACCESS:     dobles t = cos (* (doble *) NULL);

Answer 2

Objetivo C se construye directamente sobre C, y las bases C y puede hacer el trabajo.

Para un ejemplo del uso de math.h y partes de biblioteca estándar desde dentro de un módulo de C Objetivo, véase:

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

Hay otros ejemplos alrededor.

Se necesita algo de atención durante todo pasa alrededor de las variables; utilizar las variables de C para el C y llamadas a las bibliotecas estándar; no mezcle los tipos de datos y tipos de datos C C Objetivo imprudentemente. Por lo general, desea una conversión aquí.

Si ese no es el caso, entonces por favor considere publicar el código implicado, y el error (s) que está recibiendo.

Y con todo el respeto debido a la respuesta del Sr. Hellman, he golpeado errores cuando no tengo los archivos de cabecera incluidos; Yo prefiero incluir las cabeceras. Pero entonces, tiendo a marcar los diagnósticos del compilador un par de muescas, también.

Answer 3

Por lo que vale, no lo incluya en mi aplicación math.h cacao pero no tienen ningún problema usando funciones matemáticas (en C).

Por ejemplo, utilizo atan () y no obtener errores de compilación, o ejecutar los errores de tiempo.

Se puede probar esto sin incluir math.h en absoluto?

Answer 4

En primer lugar, se debe añadir el código a su pregunta, en lugar de publicar como una respuesta, por lo que la gente puede ver lo que estás preguntando. En segundo lugar, usted tiene todo tipo de problemas extraños con su gestión de memoria aquí -. GFileByteCount se utiliza para el tamaño de un grupo de tampones sino que está establecido en cero, y no aparece para obtener re-establecer en cualquier lugar

  

err = AudioFileReadPackets (fileID,   falso, y bytesReturned, NULL, 0,   Y paquetes, (Byte *) rawaudio);

Por lo tanto, en este punto, se pasa un búfer de tamaño cero a AudioFileReadPackets, que desborda puntualmente el montón, corrompiendo el valor de quien sabe que otras variables ...

  

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

Esto es otra, menor error - que desea sizeof (* fRawAudio) aquí, ya que está tratando de asignar una matriz de flotadores, no una matriz de punteros de flotación. Afortunadamente, esas entidades son del mismo tamaño, por lo que no importa.

Probablemente debería comenzar con un código de ejemplo que sepa que funciona (SPEAKHERE?), Y modificarlo. Sospecho que hay otros problemas similares en el código yoou publicado, pero no tengo tiempo para encontrarlos en este momento. Al menos conseguir el tampón rawaudio de tamaño adecuado y utilizar los valores devueltos de AudioFileReadPackets adecuadamente.