Problem when debugging piece of code while execution works

[skirby]

Hello,

As I don't know if it is the good place to post that but here is my problem.

When I debug this piece of code, I have the following error message:


If I click on Yes, here is what I have on the screen:


Otherwise, If I execute it directly, it works perfectly.

Code

#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;
}

So, is my code wrong or is it a bug of the debugger?

Thanks and have a nice day.

[sethjackson]

Well I really don't know, but umm this doesn't look good to me:

Code: cpp

s[i] = (unsigned char*)malloc(MAX);

when above you:

Code: cpp

s = (unsigned char**)malloc(MAX);

So generally if you get SIGSEV your code has a problem......

[Game_Ender]

sethjackson, that is the proper way to dynamically allocate a 2 dimensional array in C.  From a single read through, your code looks correct skirby. I would bring up the stack trace window and see where the seg fault was triggered from.

EDIT: if thats straight C code you don't need the casts.

[killerbot]

the code is WRONG :

there's a problem in the allocation of the array for the pointers, it has size of MAX bytes, which is 10.
It should be MAX * sizeof(unsigned char*).


Cheers

[MortenMacFly]

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.
With regards, Morten.

[rcoll]

Killerbot is correct, he is not allocating enough memory to **s.
Change that first allocation to from

s = (unsigned char**)malloc(MAX);

to

s = (unsigned char**)malloc(MAX * sizeof(char *));

and then run it again.

-- Ron --

[Game_Ender]

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.

[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.

Umm what do you mean by "I guess you trust you instincts and not listen to me sethjackson "?

[rcoll]

Umm what do you mean by "I guess you trust you instincts and not listen to me sethjackson "?

Will the real "sethjackson" please stand up?   

-- Ron --

[rcoll]

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.

Actually "Killerbot" found it first, I just expounded on it.

Cheers,
Ron

[skirby]

Thanks everyboby for your answer 

As often (always) killerbot was right.

That's why the debugger thrown an error message.
The debugger is always right  :lol:

As sethjackson said:

So generally if you get SIGSEV your code has a problem......

[thomas]

As sethjackson said:

So generally if you get SIGSEV your code has a problem......

This, however, is not generally true. You can very easily get a segfault with code that is 100% good.

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 

[sethjackson]

As sethjackson said:

So generally if you get SIGSEV your code has a problem......

This, however, is not generally true. You can very easily get a segfault with code that is 100% good.

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 

And strike three.  :lol:  :oops:

* wanders off *

[killerbot]

there are a few things I'd like to add :

1) in this case : the array of pointer could have been created statically, then the problem would not arise. As long as things are not too big so they fit nicely on the stack, just create them there and not from the heap

2) when sticking to the heap case, always initialize memory you get. So the array of pointers should have been directly initialized to 0 ( yes 0 : not NULL, the 'fake' (key)word NULL is not standard, the number 0 is !!!) that way you would have gotten a crash (on PC) directly because of dereferencing NULL and not some weird outbounded random value which then acts as the memory address. Offcourse when the memset would also have worked with the incorrect length then again you end up at the random values. But then you had to make the mistake twice ( or once if you would have made a variable out of the length).
[memset(s, 0, MAX*sizeof(*s))]
Why 'sizeof(*s)" : if the type of s changes I don't have to adjust this statement <--> sizeof(char) becoming sizeof(int)

Note : I said on PC, because on embedded platforms the address 0 just acts as any regular address, you are just screwing up things somewhere else :-(

RAII : Resource Acquisition Is Initialisation

Extra Note : Alexandrescu has sone nifty methods for trying to catch some of these kind of related ( ;-) ) issues at compile time, but then the static allocation would have been needed. Well , more or less.