I can't add anything particularly constructive to this thread as I'm struggling to understand the problem (you're being purposely vague).

However, the below code (copy-pasted from your original post) has a glaring problem:
[color="#1C2837"]
cat2 = (float*)realloc(cat, newsize);
if(!cat2) cat2 = (float*)realloc(cat, newsize);
cat=cat2;


[color="#1C2837"]Why are you calling realloc() twice on cat2? What's more, your if() does not encompass the following "cat=cat2", which means that if the second realloc returns null, you're back to your old problem.
[color="#1C2837"]In other words, the above code is equivalent (but more processor-intensive) to: cat = (float*)realloc(cat,newsize);

[color="#1C2837"]Did you mean:

cat2 = (float*)realloc(cat, newsize);
if(!cat2) cat = cat2;


[color="#1C2837"]by any chance?
I'd avoid using single-statement if()'s anyway, since they can cause confusion. That said, I often use them myself because I'm lazy and stubborn.

I think it has already been answered, since the standard requires compilers to leave the memory untouched in a realloc fail that's the way one can expect compilers to work. The OP is focused on an environment where one can expect realloc failing to allocate. I agree the code has a problem if both realloc's fail.

If one was really paranoid one could maybe use self-modifying techniques to make sure the app code itself is not corrupted. Or make it a one-app OS by modifying the kernel.

I am now into an application, a very important part of a linux based operating system. Becouse of this, this application cant afford itself to crash, even if the system ram and the cpu fails a bit. This application uses OpenGL and based on my existing multimedia engine. For this, i am implemented some code redundancy, and a lot other tricks, like double array boundary tests before access, etc.

After i have implemented this extreme redundancy, i tested the application on a bit broken old machine. I overclocked it, placed damaged heatstinks on it, the mainboard in that computer was broken aniway (some wires on the mainboard was deeply cutted so not any pheripherias was able to work).



In this system, i got the folowing results:

Windows operating system: explorer.exe crashed after 40-50 minute forever.
Linux operating system: desktop applications in linux (part of kde) randomly crashed in every 2-10 minutes (gnu stability strikes again)
My application (running on windows) BEFORE the redundancy add-ons: crashed 1x from 5 start, crashed after ~20 mins of work
My application (running on windows) AFTER the redundancy add-ons: application not crashed for 5-6 hours, then windows BSOD-ed.

This app cant exit from a small electronic spike coming from the power cables, or from a confusion in the force caused by Jedis.
The show must go on aniways.

Close enough. I think my goal is reached about stability with this, but there is a thing wich cant go into my mind:

realloc.

realloc, if fails, returns null, and i started to use too much reallocs in the extended versions for now. So:

cat = (float*)realloc(cat, newsize);

if this nulls, it will destroy the cat pointer that had precious data. If malloc, i can retry it again, but not with realloc.

Is realloc destroys the memory area of cat, if it fails?

for example, if i realloc cat and put the result to a different pointer like this:
cat2 = (float*)realloc(cat, newsize);
if(!cat2) cat2 = (float*)realloc(cat, newsize);
cat=cat2;

will this help to me? I mean, will cat still store the correct data, if realloc fails?
-If not, then i may can use this code.
-If it destroys it, then i should create an own, secure realloc implementation, wich will be probably mutch slower than the built in.
-Or, maybee realloc is protected against instability? I dubt, becouse malloc is also not protected against it.

Any hints are welcome.

is there speedup from realloc ?

for opengl app stability on linux trapping video adapter exceptions/faults is first.

yes, correct. on linux, if cpu is failing a bit, the graphics driver knocks the kernel out shortly.