Appel de fonctions à partir de la fonction (float * VeryBigArray, à long SizeofArray) à partir de la méthode objc échoue avec EXC_BAD_ACCESS

Question

Ok j'ai finalement trouvé le problème. Il était à l'intérieur de la fonction C (CarbonTuner2) pas la méthode objc. Je créais dans la fonction d'un tableau de la même taille que la taille du fichier si la taille du fichier a été grand, il a créé un tableau vraiment grand et je suppose que quand j'ai appelé une autre fonction à partir de là, les variables locales ont été mises sur la pile qui créé le EXC_BAD_ACCESS. Ce que je ne puis est au lieu d'utiliser une variable de déclarer à la taille du tableau, je mets directement le numéro. Ensuite, le code na pas même compiler. il savait. L'erreur wassomething comme: taille Array trop grand. Je suppose que travaille 20 + heures d'affilée isnt bonne XD Mais je suis en va regarder definitly autres outils que l'étape par debuggin étape pour comprendre ceux-ci dehors. Merci de votre aide. Voici le code. Si vous divisez gFileByteCount par 2, vous ne trouverez jamais plus l'erreur:

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

Votre accident n'a rien à voir avec les incompatibilités entre C et ObjC. Et comme dit des affiches précédentes, vous n'avez pas besoin d'inclure math.h.

Exécuter votre code sous gdb, et voir où l'accident se produit à l'aide backtrace.

Êtes-vous sûr que vous n'êtes pas envoyer de mauvais arguments aux fonctions mathématiques?

par exemple. ce qui provoque BAD_ACCESS:     doubles t = cos (* (double *) NULL);

Answer 2

Objectif

C est construit directement sur C, et les fondements C et peut faire le travail.

Pour un exemple d'utilisation math.h et des parties de la bibliothèque standard à partir d'un module Objective C, voir:

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

Il existe d'autres exemples autour.

Certains soins est nécessaire autour de passer les variables autour; utiliser les variables C pour le C et les appels de la bibliothèque standard; ne pas mélanger les types de données C et Objective types de données C inconsidérément. Vous aurez généralement voulez une conversion ici.

Si ce n'est pas le cas, alors s'il vous plaît envisager d'afficher le code impliqué, et l'erreur (s) que vous recevez.

Et avec tout le respect dû à la réponse de M. Hellman, j'ai frappé des erreurs quand je n'ai pas les fichiers d'en-tête inclus; Je préfère inclure les en-têtes. Mais alors, je tends à composer le diagnostic du compilateur jusqu'à deux crans aussi.

Answer 3

Pour ce que ça vaut, je ne comprend pas math.h dans mon application Cocoa, mais avoir aucun problème à l'aide de fonctions mathématiques (en C).

Par exemple, j'utilise atan () et ne pas les erreurs du compilateur, ou les erreurs d'exécution.

Pouvez-vous essayer cela sans inclure math.h du tout?

Answer 4

Tout d'abord, vous devez ajouter votre code à votre question, plutôt que de l'afficher comme une réponse, afin que les gens puissent voir ce que vous demandez au sujet. Deuxièmement, vous avez toutes sortes de problèmes étranges avec la gestion de votre mémoire ici -. GFileByteCount est utilisé pour dimensionner un tas de tampons, mais il est mis à zéro et ne semble pas se mettre en re-partout

  

err = AudioFileReadPackets (fileID,   faux, & bytesReturned, NULL, 0,   & Paquets, (octet *) rawaudio);

Donc, à ce stade, vous passez un tampon de taille zéro à AudioFileReadPackets, qui dépassements prompty le tas, corrompant la valeur qui sait ce que d'autres variables ...

  

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

Voici une autre erreur mineure - vous voulez sizeof (* fRawAudio) ici, puisque vous essayez d'allouer un tableau de chars, pas un tableau de pointeurs de flotteur. Heureusement, ces entités ont la même taille, de sorte qu'il n'a pas d'importance.

Vous devriez probablement commencer par quelques exemples de code que vous connaissez des œuvres (SpeakHere?), Et le modifier. Je soupçonne qu'il ya d'autres problèmes similaires dans le code yoou affiché, mais je ne suis pas le temps de les trouver en ce moment. Au moins obtenir le tampon rawaudio de taille appropriée et utiliser les valeurs renvoyées de AudioFileReadPackets correctement.