#include <stdio.h>
#include <stdlib.h>
#define MAX 10
int main(void) {
int i;
unsigned char** s;
s = (unsigned char**)malloc(MAX);
if (s == NULL) {
printf("Error allocating s\n");
return -1;
}
for (i = 0; i < MAX; i++) {
s[i] = (unsigned char*)malloc(MAX);
if (s[i] == NULL)
printf("Error allocating s[%d]\n", i);
else
sprintf((char*)s[i], "test %d", i);
}
for (i = 0; i < MAX; i++) {
if (s[i] != NULL)
printf("s[%d] : %s\n", i, s[i]);
free(s[i]);
}
free(s);
return 0;
}
s[i] = (unsigned char*)malloc(MAX);
s = (unsigned char**)malloc(MAX);
When I debug this piece of code, I have the following error message:Do you mind telling us the C::B/GDB versions you are using? At what line the debugger crashes? I can debug through this code just fine using revision 2829. I don't see any problem. Please try to be more descriptive, e.g. a step-by-step instrcution how to reproduce this crash.
s = (unsigned char**)malloc(MAX * sizeof(char *));
and then run it again.
-- Ron --
s = (unsigned char**)malloc(MAX * sizeof(char *));
and then run it again.
-- Ron --
You have better eyes than I Ron and I guess you trust you instincts and not listen to me sethjackson ;). I should of checked more carefully.
I have made the mistake of not even allocating the space for the pointers first, or doing only the pointers and not the elements and that was the main thing I was checking. Of course a backtrace from the debugger is usually more helpful than starting at the code just hoping the error will pop out at you. It should of failed trying to write the 3rd test message.
Umm what do you mean by "I guess you trust you instincts and not listen to me sethjackson ;)"?
s = (unsigned char**)malloc(MAX * sizeof(char *));
and then run it again.
-- Ron --
You have better eyes than I Ron and I guess you trust you instincts and not listen to me sethjackson ;). I should of checked more carefully.
I have made the mistake of not even allocating the space for the pointers first, or doing only the pointers and not the elements and that was the main thing I was checking. Of course a backtrace from the debugger is usually more helpful than starting at the code just hoping the error will pop out at you. It should of failed trying to write the 3rd test message.
So generally if you get SIGSEV your code has a problem......
As sethjackson said:This, however, is not generally true. You can very easily get a segfault with code that is 100% good.QuoteSo generally if you get SIGSEV your code has a problem......
As sethjackson said:This, however, is not generally true. You can very easily get a segfault with code that is 100% good.QuoteSo generally if you get SIGSEV your code has a problem......
Try drag and drop with an application run from the debugger on a Windows XP system, for example. File selector boxes work alike, and so do a couple of thread synchronisation functions. These generally produce general segfault messages although the code has generally no problem :)