SIGBUS on realloc()

[krishna chaithanya]

Hi,

I have seen a SIGBUS when calling realloc() in my code.

Code is as simple as this:

char* str = NULL;
str = realloc(str,10); /*this is not the actual code but resembles*/

Can anyone please let me know what could be the cause of a SIGBUS on such a code?

Also, I would be grateful if anyone can provide all the reasons in the world to cause a SIGBUS.

Thanks and Regards,
krishna

[tetsujin]

Hi,

I have seen a SIGBUS when calling realloc() in my code.

Code is as simple as this:

char* str = NULL;
str = realloc(str,10); /*this is not the actual code but resembles*/

"Not the actual code" is a bit of a problem. There is no reason the above code should fail - and I'm guessing it doesn't. Therefore something about the rest of your code is causing the failure...

Did you include stdlib.h? Are you sure (str) is still null when the realloc call happens? (Simply being sure that you didn't set it to anything else is not enough... If another piece of your code is overwriting arbitrary memory, then the value of (str) could be changed...)

[Rubberman]

You cannot realloc() a null pointer since there is no size information, hence the SIGBUS exception. You need to check and if the pointer is null then you can malloc or calloc it.

[tetsujin]

You cannot realloc() a null pointer since there is no size information, hence the SIGBUS exception. You need to check and if the pointer is null then you can malloc or calloc it.

Actually, according to the manpage for realloc(), realloc(0, N) is equivalent to malloc(N), and realloc(P, 0) where (P != 0) is equivalent to free(P). So the usage is legit. The following program, for instance, works fine:

#include <stdlib.h>
#include <string.h>

int main()
{
    char* p = 0;

    p = realloc(p, 20);
    strcpy(p, "Floog is winner.");
    p[15] = '!';

    puts(p);

    p = realloc(p, 0);

    return 0;
}

[Rubberman]

Actually, according to the manpage for realloc(), realloc(0, N) is equivalent to malloc(N), and realloc(P, 0) where (P != 0) is equivalent to free(P). So the usage is legit. The following program, for instance, works fine:

#include <stdlib.h>
#include <string.h>

int main()
{
    char* p = 0;

    p = realloc(p, 20);
    strcpy(p, "Floog is winner.");
    p[15] = '!';

    puts(p);

    p = realloc(p, 0);

    return 0;
}

You are correct. This is currently the case with FULLY ANSI compliant compilers, but this was not always the case, and there are a lot of Unix systems and C compilers other than gcc out there where this will not work. So, if you are building cross-platform applications, making this assumption is deadly!

[krishna chaithanya]

Thanks for all the inputs.

But, my second part of the question is not answered!

I want to know all the reasons in the world which can cause SIGBUS. I have searched in google but couldn't get much.

[Rubberman]

From the Wikipedia:

On POSIX-compliant platforms, SIGBUS is the signal sent to a process when it causes a bus error.

and

In computing, a bus error is generally an attempt to access memory that the CPU cannot physically address. Bus errors can also be caused by any general device fault that the computer detects. A bus error rarely means that computer hardware is physically broken - it is normally caused by a bug in a program's source code.

The size information for a chunk of memory allocated on the heap is just before the address returned by malloc/calloc/realloc. So, unless your realloc can deal with null pointers correctly, it is trying to access memory that doesn't exist, hence the crashing sound you hear.

[tetsujin]

Thanks for all the inputs.

But, my second part of the question is not answered!

I want to know all the reasons in the world which can cause SIGBUS. I have searched in google but couldn't get much.

I don't have the magic answer to your question.

It's like I said, I need more information. I gave you some possible reasons why this might be happening - but you're going to have to answer my questions before I can help you further.

[krishna chaithanya]

I don't have the magic answer to your question.

It's like I said, I need more information. I gave you some possible reasons why this might be happening - but you're going to have to answer my questions before I can help you further.

Actually, I have shown one example in my system for SIGBUS. Mine is a very complex project where SIGBUS seem to happen many times. So, I just picked an example and asked for the reasons for SIGBUS.

Coming to the example I have given, I can't give u the exact code but it looks like this.

void func()
{
char *list = NULL;
char str[1024];
int cur = 0;
int buflen = 0;
int count == 0;

while()
{
scanf("%s",str);
scanf("%d",&count);
if(count == 0)
break;
buflen = strlen(str);
list = realloc(list, cur+buflen);
if(cur > 0) {
list[cur++] = ' ';
}
cur += sprintf(&list[cur], "%s:%d", str, count);
}
}

Please don't try to understand what I am trying to do with the code but just let me know if anything is wrong with the code.

Thanks and Regards,
krishna

[tetsujin]

void func()
{
  char *list = NULL;
  char str[1024];
  int cur = 0;
  int buflen = 0;
  int count == 0;

  while()
  {
     scanf("%s",str);
     scanf("%d",&count);
     if(count == 0)
       break;
     buflen = strlen(str);
     list = realloc(list, cur+buflen);
     if(cur > 0) {
       list[cur++] = ' ';
     }
     cur += sprintf(&list[cur], "%s:%d", str, count);
  }
}

Well, there's a bug... You resized list[] to be large enough to hold the current data, plus strlen(str) - but then you copy at least (strlen(str) + 3) bytes on beyond the current data. (You copy in str, plus a colon, an integer, and a null terminator.) In some cases you copy a space in there, too...

Writing past the end of your allocation can always mess things up - sometimes it'll mess things up immediately (with a segmentation fault), other times it will just leave some other piece of data in an invalid state, causing something else to fail later on.