Gratch06
asked on
malloc + Null pointer error.
This is one of my first times toying with malloc, so I'm probably overlooking something really simple. Here are the relevant lines to the problem at hand...
typedef struct Racer{
char* sName;
sh_int oddsFor;
sh_int oddsAgainst;
} RCR_MDL;
typedef struct ChariotOrganization{
int timer;
int numberOfRacers;
RCR_MDL* RacerList;
} CHRT_MDL;
int main(){
...
chariot = alloca(sizeof(CHRT_MDL));
chariot->RacerList = alloca(10 * sizeof(RCR_MDL)); //max 10 racers
chariot->numberOfRacers = 0; //default it to 0
addRacer("The King's Centurion", 3, 2);
addRacer("The Amazon", 2, 1);
addRacer("The Jackal", 3, 1);
addRacer("The White Rabbit", 5, 1);
addRacer("The Village Idiot", 10, 1);
...
}
void addRacer(char* racerName, int oddsAgainst, int oddsFor){
int racerNumber = chariot->numberOfRacers++;
chariot->RacerList[racerNu mber].sNam e = malloc(strlen(racerName));
//------------------------ ---------- ---------- ---------- --------//
printf(""); //WHY? <-------------------- problem line
//------------------------ ---------- ---------- ---------- --------//
strcpy( chariot->RacerList[racerNu mber].sNam e, racerName); <--- generates NULL pointer error
chariot->RacerList[racerNu mber].odds Against = oddsAgainst;
chariot->RacerList[racerNu mber].odds For = oddsFor;
}
My issue is that I must have that printf statement there for the program to operate properly. It doesn't matter what I print out, so long as I use printf at some point between the allocation and strcpy. The error occurs while adding the fifth name, and I've traced it to the strcpy line in the addRacer function. It complains that it can't write to 0x00000000, hence malloc returns a NULL pointer, yet when I added a printf statement to validate this, the program immediately started working again as planned, without the NULL pointer errors. Any guidance is much appreciated.
typedef struct Racer{
char* sName;
sh_int oddsFor;
sh_int oddsAgainst;
} RCR_MDL;
typedef struct ChariotOrganization{
int timer;
int numberOfRacers;
RCR_MDL* RacerList;
} CHRT_MDL;
int main(){
...
chariot = alloca(sizeof(CHRT_MDL));
chariot->RacerList = alloca(10 * sizeof(RCR_MDL)); //max 10 racers
chariot->numberOfRacers = 0; //default it to 0
addRacer("The King's Centurion", 3, 2);
addRacer("The Amazon", 2, 1);
addRacer("The Jackal", 3, 1);
addRacer("The White Rabbit", 5, 1);
addRacer("The Village Idiot", 10, 1);
...
}
void addRacer(char* racerName, int oddsAgainst, int oddsFor){
int racerNumber = chariot->numberOfRacers++;
chariot->RacerList[racerNu
//------------------------
printf(""); //WHY? <-------------------- problem line
//------------------------
strcpy( chariot->RacerList[racerNu
chariot->RacerList[racerNu
chariot->RacerList[racerNu
}
My issue is that I must have that printf statement there for the program to operate properly. It doesn't matter what I print out, so long as I use printf at some point between the allocation and strcpy. The error occurs while adding the fifth name, and I've traced it to the strcpy line in the addRacer function. It complains that it can't write to 0x00000000, hence malloc returns a NULL pointer, yet when I added a printf statement to validate this, the program immediately started working again as planned, without the NULL pointer errors. Any guidance is much appreciated.
ASKER
>any special reasons for using alloca ?
adjusted main:
chariot->RacerList = (RCR_MDL *)malloc(10 * sizeof(RCR_MDL));
chariot->numberOfRacers = 0;
addRacer("The King's Centurion", 3, 2);
addRacer("The Amazon", 2, 1);
addRacer("The Jackal", 3, 1);
addRacer("The White Rabbit", 5, 1);
addRacer("The Village Idiot", 10, 1);
> chariot->RacerList[racerNu mber].sNam e = (char *) malloc(strlen(racerName));
> It is always good to check return value from malloc .. It is not very wise to skip such error checks
Adjusted addRacer function:
void addRacer(char* racerName, int oddsAgainst, int oddsFor){
int racerNumber = chariot->numberOfRacers++;
if(!(chariot->RacerList[ra cerNumber] .sName = (char *) malloc(strlen(racerName))) ){
printf("Invalid allocation in addRacer function");
return;
}
printf(""); //WHY?
strcpy( chariot->RacerList[racerNu mber].sNam e, racerName);
chariot->RacerList[racerNu mber].odds Against = oddsAgainst;
chariot->RacerList[racerNu mber].odds For = oddsFor;
}
The identical error still exists in this code. It hangs up on the fifth call, with the printf(""); line out, but with it in, runs perfectly.
>Why printf solves the problem is really strange ... unless you have multithreaded application with race conditions...
Nothing near that complex. It's just a very simple routine at this stage, and this is my starting point.
>could it be some compiler optimization gone wrong ... thin chance for that though but it is a possibility
I'm using the Dev C++ v. 4.8.9.0 compiler currently. I tried compiling it using gcc on a linux box, and that compiled and ran perfectly both with and without the printf(""); statement.
adjusted main:
chariot->RacerList = (RCR_MDL *)malloc(10 * sizeof(RCR_MDL));
chariot->numberOfRacers = 0;
addRacer("The King's Centurion", 3, 2);
addRacer("The Amazon", 2, 1);
addRacer("The Jackal", 3, 1);
addRacer("The White Rabbit", 5, 1);
addRacer("The Village Idiot", 10, 1);
> chariot->RacerList[racerNu
> It is always good to check return value from malloc .. It is not very wise to skip such error checks
Adjusted addRacer function:
void addRacer(char* racerName, int oddsAgainst, int oddsFor){
int racerNumber = chariot->numberOfRacers++;
if(!(chariot->RacerList[ra
printf("Invalid allocation in addRacer function");
return;
}
printf(""); //WHY?
strcpy( chariot->RacerList[racerNu
chariot->RacerList[racerNu
chariot->RacerList[racerNu
}
The identical error still exists in this code. It hangs up on the fifth call, with the printf(""); line out, but with it in, runs perfectly.
>Why printf solves the problem is really strange ... unless you have multithreaded application with race conditions...
Nothing near that complex. It's just a very simple routine at this stage, and this is my starting point.
>could it be some compiler optimization gone wrong ... thin chance for that though but it is a possibility
I'm using the Dev C++ v. 4.8.9.0 compiler currently. I tried compiling it using gcc on a linux box, and that compiled and ran perfectly both with and without the printf(""); statement.
>I'm using the Dev C++ v. 4.8.9.0 compiler currently. I tried compiling it using gcc on a linux box, and that compiled and ran
>perfectly both with and without the printf(""); statement.
In that case it is in all probabilities a compiler/library specific issue ... try turning off any optimizations
>perfectly both with and without the printf(""); statement.
In that case it is in all probabilities a compiler/library specific issue ... try turning off any optimizations
ASKER
>In that case it is in all probabilities a compiler/library specific issue ... try turning off any optimizations
I've compiled it with both full optimizations and no optimizations (as much as I am able to specify) with no change of behavior.
I've compiled it with both full optimizations and no optimizations (as much as I am able to specify) with no change of behavior.
ASKER CERTIFIED SOLUTION
membership
This solution is only available to members.
To access this solution, you must be a member of Experts Exchange.
ASKER
>chariot->RacerList[racerN umber].sNa me = (char *) malloc(strlen(racerName) + 1);
That did the trick. It makes sense to me now that the strlen would give the number of chars, not including the null terminating char at the end, but in copying, it would do the null-terminating character as well. I'm curious to know why trying to write past the end of a char array would be trying to access null instead of some other location in memory.
>try compiling this
>int main ()
>{
> char * a = "abcd";
> char * b = malloc ( strlen (a) + 1 );
> strcpy ( b, a );
> printf ( "%s\n", b );
> free(b);
>}
Now I'm all confuzzled...this works fine both with and without the + 1...go figure. Anyway, I understand the flaw in my logic, and I have a solution that satisfies me, so points are now awarded. Thanks for the help sunnycoder.
That did the trick. It makes sense to me now that the strlen would give the number of chars, not including the null terminating char at the end, but in copying, it would do the null-terminating character as well. I'm curious to know why trying to write past the end of a char array would be trying to access null instead of some other location in memory.
>try compiling this
>int main ()
>{
> char * a = "abcd";
> char * b = malloc ( strlen (a) + 1 );
> strcpy ( b, a );
> printf ( "%s\n", b );
> free(b);
>}
Now I'm all confuzzled...this works fine both with and without the + 1...go figure. Anyway, I understand the flaw in my logic, and I have a solution that satisfies me, so points are now awarded. Thanks for the help sunnycoder.
>I'm curious to know why trying to write past the end of a char array would be trying to access null instead of some other
>location in memory.
There has to be some inaccuracy somewhere ... it is illegal access violation
>Now I'm all confuzzled...this works fine both with and without the + 1...go figure.
access is still illegal ... just that it is not offending some other process ... its chance that it is getting through not logic :o)
>location in memory.
There has to be some inaccuracy somewhere ... it is illegal access violation
>Now I'm all confuzzled...this works fine both with and without the + 1...go figure.
access is still illegal ... just that it is not offending some other process ... its chance that it is getting through not logic :o)
> chariot->RacerList = alloca(10 * sizeof(RCR_MDL)); //max 10 racers
any special reasons for using alloca ?
>chariot->RacerList[racerN
should be
chariot->RacerList[racerNu
>It complains that it can't write to 0x00000000, hence malloc returns a NULL pointer, yet when I added a printf statement to
>validate this, the program immediately started working again as planned, without the NULL pointer errors.
It is always good to check return value from malloc .. It is not very wise to skip such error checks
Why printf solves the problem is really strange ... unless you have multithreaded application with race conditions...
could it be some compiler optimization gone wrong ... thin chance for that though but it is a possibility