calloc () is used to allocate and clear space for the a data set as a typedef struct. One structure is allocated. The structure contains 10 char xxx[3];
variables.
Data can be loaded into the structure and it all checks. When space for a second set of data is created using realloc (ptr,2) - the data in the first structure
second string is corrupted. The first and subsequent strings are correct.
Data entered into the second structure is correct. Space for a third set of data
is realloc(ptr,3) and all data in second is correct. First structure second string
is still corrupt.
The first set of data can be entered and more space realloc and it is all correct.

Any clues.
This code compiles and runs without error or warnings. Runs fine on several
Unix machines but not on Suse 11 linux.

Any clues.

Can u post piece of code ?

Are the other UNIX machines also Linux systems, or is Suse the only Linux box involved?
Is it the same on another Suse installation?
Is it always the same memory area that is trashed?
Did you run the code via 'ddd' to debug it in detail?
Does it produce the same result when run via 'ddd' as it does on a normal run?
Do all involved systems use the same GCC and GLIBC combination?
Tried to compile it with another compiler (like LCC or Intel)?

The source code is probably not at fault, if it runs correctly on other systems. It seems like something is trashing the memory area of the application. It can even be a problem within glibc.

Linux Archive

Do you mean that literally? You did a realloc to change the size to be 2 bytes?

If you mean realloc(ptr,2*sizeof(whatever_type)) then you should say so.

Good suggestion.

Nonsense! The source code is almost certainly at fault. It probably runs correctly because of luck. You can clobber quite a bit of heap memory that you incorrectly think you allocated and work anyway (by luck) especially in a short simple program.

I admit that 'realloc (ptr,2)' effectively does the trashing itself, so that would be really a problem in the source code. I just wonder, why the same line of code behaves 'correctly' on other UNIXes. This would mean that all other UNIX systems run it correctly "by luck" - effectively meaning that all the other systems are buggy for depending on luck.

Luck is not really a well defined concept in programming. But 'realloc' has a well-defined standard definition, so I still keep up my theory that some system library can be at fault: either in Suse, or in all those other "lucky" UNIX systems (even if their fault is by hiding the error and making some assumption on how to behave).

Is there any standard way to acquire such "coding luck" for programming? A lot of people could use it.

If he meant that literally, which seems very possible, that is what does the trashing.

Obviously, the line of code wound not behave correctly. But the program might run to completion with correct output.


I don't get that interpretation at all. The other systems don't "depend" on any luck. They assume the program makes correct calls.

In a well designed system a correct program produces correct results.

It would be impossible to design a system in which every incorrect program produces incorrect results. Even after reading the programmer's mind to deduce intent, you would still run into the decidability issues in correctness.

Sometimes an incorrect program will produce "correct" output.

Hardly! If you're a serious programmer that would be bad luck. It means you tested your program and it worked, but it is still wrong and under other conditions it will crash.

I'm much happier when broken programs fail the simplest test, than when one runs perfectly for six years of serious use by many people, then fails on a totally ordinary example and takes days of debugging (last week) to find a serious coding error that took a massive amount of "luck" to not crash far more often.

If it had failed any of the initial tests I would have spotted the bug without even debugging. If the 64bit Visual Studio debugger were not seriously flawed I would have found the bug in a few minutes of debugging Unfortunately gdb shares the important bugs that got in my way. Win32 was the one platform I use with a good enough (obsolete Visual Studio) debugger for this bug and the one platform where the bug got "lucky" and never appeared.

The code is text book stuff and simple. It compiles without any warning's and
with gdb you can see what happens.
I moved the program so it was not using the same memory by runnin another program before and let it run in an endless loop. When I inspected the pointer it was to
another place in memory. I looked to see if there was trash on the stack and it
all made sense.
I did a 12 memory test on the target mach. to make usre I was not looking at a
HW problem.

It was clearly stated that the ptr was pointer to a structure. The space
for it was created at run time by ptr = (STR *)calloc(1, sizeof(STR));
You can see the contents in the gdb by using *ptr -- (note calloc args are
reversed from malloc() )

It displays all of the contents.
realloc () knows what the size is from the orig calloc.
realloc (ptr,2) means that it will allocate one more structure in memory.
You can see this with gdb p *(ptr+1). This shows you the contents of the second
structure. To really test the problem I filled each structure with data and
every structur's contents were perfect.
Read Std "C".

There is no such function in "C" called luck()

You can see the corrupted first structure immediately after realloc () is run.

The program compiles with a warnings or errors.

If you create a temp ptr and set the temp ptr to tptr = ptr + 1;
You can realloc() for a least a dozen cases without any problems. It is always
the first structure - second member that is corrupted!

Is there an online copy anywhere for whatever documentation told you that? It contradicts every example of realloc documentation I can find.

Memory doesn't usually fail to exist nor even fail to work just because you allocated it incorrectly.

It is not surprising that you can see the contents of the second structure even after the memory it occupied has been released back to the free pool by your incorrect realloc.

Freeing a chunk of memory typically modifies just the first few bytes of the freed memory (exactly fitting your described symptom). (2 bytes is below a minimum chunk size, so the beginning of the freed memory is likely more than 2 bytes past the initial pointer).

Interesting problem. Ijlinde, can you provide a subset of your code which displays the problem?