Need quick help - C memory management

[Strike]

Okay, I'm admittedly more of a C++ programmer than a C programmer in terms of what conventions I usually follow, so I rarely ever do dynamic memory in C... hence I'm boggled by why what I'm doing is not working.

What I was trying to do was to write a simple normalizing program that will take several WAV inputs and normalize them all to a similar scale. That's unimportant, but I just thought I'd let you know what this was for in case that spurred some interest. Anyway, here's the offending code:


... blah blah, stuff here ...

long *frames;

... blah blah, more stuff ...

frames = (long *)calloc((size_t)frame_count, sizeof(long));


(frame_count is fine)
The code works fine (compiles, no errors), but when I try to use frames, like so:


err = afReadFrames(original_fh, AF_DEFAULT_TRACK, &frames, (int)frame_count);


(afReadFrames, original_fh, AF_DEFAULT_TRACK, and frame_count are all fine)
...it still compiles fine, but I get the message "Command Terminated" every time I run the code. Is my syntax wrong?

[sans-hubris]

Whoa, strike needs help on something?

Anyway, it looks you're trying to typecast frame_count, which I assume is an float or a double? Isn't "Command Terminated" one of the exceptions that can be thrown?

[ 30 April 2001: Message edited by: ndogg.cpp ]

[Strike]

I'm pretty sure the typecast is safe, I was just doing that to eliminate that as a weird possibility for error (not thinking that I might cause another). Lemme change that up and see if it fixes anything, though I doubt it will.

[sans-hubris]

Strike, I am pretty sure I'm right about that, "Command Terminated" is usually the response programs give if they are sent the TERM signal. However, I'm not sure why your program would be sent that signal.

[ 01 May 2001: Message edited by: ndogg.cpp ]

[Stuka]

Strike,
It's a long shot, but how high does frame_count go? Is it possible that it goes out of range for an unsigned int? I assume your checking the pointer before you use it, so that shouldn't be a problem, but I can't think of anything else w/o seeing more!

[Strike]

normalize.c

#include <audiofile.h>
#include <stdio.h>
#include <stdlib.h>

#define SOUND_FILE "dest.wav"

int main()
{
int err;
long *frames;
AFfilehandle original_fh;
AFframecount frame_count;

/* Step 1 - open the file */
original_fh = afOpenFile(SOUND_FILE, "r", 0);
if (original_fh == AF_NULL_FILEHANDLE) {
fprintf(stderr, "Couldn't open file %s, exiting...\n", SOUND_FILE);
exit(EXIT_FAILURE);
}

/* Step 2 - get the number of frames in the file */
frame_count = afGetFrameCount(original_fh, AF_DEFAULT_TRACK);
if (frame_count < 0) {
fprintf(stderr, "Something funky happened, frame count < 0\n");
exit(EXIT_FAILURE);
}

/* Step 3 - allocate space for all of the frames */
frames = (long *) calloc((size_t)frame_count, sizeof(long));

/* Step 4 - read all the frames in */
/*err = afReadFrames(original_fh, AF_DEFAULT_TRACK, &frames, (int)frame_count);
if (err < 0) {
fprintf(stderr, "Error reading frames from %s, quitting...\n", SOUND_FILE);
exit(EXIT_FAILURE);
}*/

/* Step ?? - close the file and return memory */
err = afCloseFile(original_fh);
if (err < 0) {
fprintf(stderr, "Error closing file %s, exiting anyway...\n", SOUND_FILE);
exit(EXIT_FAILURE);
}

free((void *)frames);

return 0;
}


compiles with:
gcc -Wall -ansi -g -o normalize normalize.c -laudiofile

perfectly fine (no errors or warnings), but when I uncomment that line mentioned above, I get "Command Terminated"

[ 01 May 2001: Message edited by: Strike ]

[Stuka]

hmm..and it terminates where? at that line? or somewhere else? The reason I ask is because in your calloc() call, you use frame_count as an unsigned int(size_t), but in your call to AfReadFrame() you cast it to an int...could it be too big for an int, but not too big for an unsigned int? That's really the only thing I can see (of course I'm no expert in C either...I definitely prefer OO, new, and delete!).

[ 01 May 2001: Message edited by: Stuka ]

[sans-hubris]

The only thing is that int and long int in x86 Linux are the same. Try casting it to a long long int when you call afReadFrames.

[augur]

Greetings,

I'm not familiar with the "audiofile" library you are using, but i noticed something unusual:

...
err = afReadFrames(original_fh, AF_DEFAULT_TRACK, &frames, (int)frame_count);
...


you are passing '&frames', the address of the pointer, not the address it points to, but maybe that's what it is expected...
The other thing i can think of is that you never check if 'frames' is a valid pointer, maybe it is not.

[Strike]

Originally posted by Stuka:
<STRONG>hmm..and it terminates where? at that line? or somewhere else? The reason I ask is because in your calloc() call, you use frame_count as an unsigned int(size_t), but in your call to AfReadFrame() you cast it to an int...could it be too big for an int, but not too big for an unsigned int? That's really the only thing I can see (of course I'm no expert in C either...I definitely prefer OO, new, and delete!).

[ 01 May 2001: Message edited by: Stuka ]</STRONG>
It terminates at the afReadFrames line. I'll check all the casting stuff, but like I said, I tried it when I knew frames was supposed to be 256 and it still gave me that error.

[Strike]

Originally posted by augur:
<STRONG>Greetings,

I'm not familiar with the "audiofile" library you are using, but i noticed something unusual:

...
err = afReadFrames(original_fh, AF_DEFAULT_TRACK, &frames, (int)frame_count);
...


you are passing '&frames', the address of the pointer, not the address it points to, but maybe that's what it is expected...
The other thing i can think of is that you never check if 'frames' is a valid pointer, maybe it is not.</STRONG>

Hmm.. the prototype for the function (according to the docs) is:

int afReadFrames (const AFfilehandle file, int track, void *samples, const int count)

and it says:

"samples is a pointer to a buffer capable of storing count frames read from the file referred to by file."

I thought that it being a void pointer was weird, but then again, the type of samples you read varies so it made sense again.

[TheLinuxDuck]

Strike:

I believe that augur is right. Because frame is already a pointer, and the function is expecting a pointer, just remove the ampersand. It can't hurt to typecast it either. (^=

Of course, I could be wrong, too.

[ 02 May 2001: Message edited by: TheLinuxDuck ]

[Strike]

Originally posted by TheLinuxDuck:
<STRONG>Strike:

I believe that augur is right. Because frame is already a pointer, and the function is expecting a pointer, just remove the ampersand. It can't hurt to typecast it either. (^=

Of course, I could be wrong, too.

[ 02 May 2001: Message edited by: TheLinuxDuck ]</STRONG>

Wow, I'm such a moron when it comes to pointer notation sometimes. Thanks, that fixed it ... so far :)