Realloc x86 x86_64

Question

I have a function

void *srealloc(void * ptr , int size){
    void *tmp = realloc(ptr , size);
    if(tmp == NULL){
        fprintf(stderr,"realloc of %u bytes failed", size);
        exit(1);
    }
    return tmp;
}

My code that calls this runs fine on an x86 computer, but when I compile and run the same code on my x64 computer I get a segfault.

An example of how this is being called is:

line = "Some string";
buffer = (char**) srealloc (buffer,sizeof(buffer)*(++buffer_lines));
buffer[buffer_lines-1] = line;

When I trace through with gdb when srealloc is called on the segfaulting computer ptr == 0x0, size == 8

*Edit: The segfault occurs on:

void *tmp = realloc(ptr, size);

Note that `sizeof(buffer)` is the size of the _pointer to pointer to char_. To be correct you should use `sizeof(char *)`. It doesn't really matter here, since the size of a pointer to one type is the same as the pointer to another type, just wanted to point this out. — Some programmer dude, Nov 25 '11 at 05:24
@JoachimPileborg Good point, I had my code like that originally, but it got changed at one point out of frustration. — LeeG, Nov 25 '11 at 05:33
Probably unrelated to your crash, but your function also has the wrong signature, it should have the same as `realloc` itself. `int` is not the correct type for "sizes", never use a signed type for such a purpose. In particular on modern 64 bit architectures `int` is usually only 32 bit where `size_t` is 64. Use `size_t` it is designed for things like this. — Jens Gustedt, Nov 25 '11 at 07:41

score 3 · Accepted Answer · answered Nov 25 '11 at 05:11

3

Your call looks fine. A crash in malloc(), realloc(), calloc() or free() is often a symptom of a bug elsewhere in your program, where you have written beyond the bounds of an allocated block and stomped over the housekeeping information used by the memory allocation functions.

Try running your program under a tool like Valgrind or Purify.

answered Nov 25 '11 at 05:11

caf

233,326
40
323
462

After running Valgrind it turns out I had a `strncpy(cp,line,strlen(line)+1)` when `cp*` was uninitialized. I assume this lead to some smashing later when I called realloc. Valgrind was a good call. – LeeG Nov 25 '11 at 05:32

score 0 · Answer 2 · answered Nov 25 '11 at 05:14

Make sure that the code calling realloc has a valid prototype for that function (in other words, include stdlib.h).

Many problems in switching from 32 to 64 bits involve the disparity between integers (the default arguments if no prototype) and pointers. While the integers may stay at 32 bits on a 64-bit platform, the pointers may be increased in size.

Since you state that the pointer is NULL and the requested size is 8, that's certainly valid use of the function. A realloc of a null pointer is effectively the same as a malloc. That's why I suspect the prototype problem.

Also make sure you're compiling everything on the new machine. You may strike problems if you try to link a 32-bit-compiled srealloc against a 64-bit-compiled client.

After running Valgrind it turns out that sending a garbage pointer to `strncpy()` was messing up my heap. This doesn't explain why my code was running on an x86 computer, but I'm glad I found the cause of this bug anyway. — LeeG, Nov 25 '11 at 05:37

Realloc x86 x86_64

2 Answers2