Countermeasures against double-open memory in background processing

Asked 1 years ago, Updated 1 years ago, 378 views

While running program a in the background multiple times simultaneously using a shell script, the following error occurs:

***Error in `a': double free or correction(!prev): 0x00000000009120b0***

We recognize that this error is caused by a double release of memory.
Program a is written in the c language and uses malloc and free to dynamically secure memory.

#defineSAFE_FREE(ptr){free(ptr);ptr=NULL;} 

j=(double*)malloc(sizeof(double)*MAX);
power=(double*)malloc(sizeof(double)*MAX);

SAFE_FREE(j);
SAFE_FREE(power);

As mentioned above, I tried to double-open the memory by replacing NULL with the pointer that I used, but I am still having trouble seeing errors due to double-open.

Is there a problem with the above program?Is it because you run it multiple times at the same time in the background?If you know how to deal with this situation, please let me know.

Thank you.

c

2022-09-30 21:53

3 Answers

I think the presentation code is for questioning, but there seems to be no problem here alone.
If you can provide the code to reproduce the problem, someone may be able to find the problem.

I'm concerned that malloc() did not specify an error check. (If NULL is returned, I probably won't be able to move the process as intended.)
I think there is no problem with the SAFE_FREE macro itself.

What comes to mind as a possibility is
·Unauthorized memory access has destroyed pointer variables.
·The malloc() pointer variable was copied to another pointer variable elsewhere, and eventually SAFE_FREE was made for both.
Is that so?

One more thing,

Is it because I run it multiple times at the same time in the background?

Multiple processes run in independent memory space, so the malloc() pointer is
There is no interference.


2022-09-30 21:53

While running program a in the background multiple times simultaneously using a shell script, the following error occurs:

Programs are managed in units of processes, and problems with one process rarely affect other processes.Therefore, it has nothing to do with booting from bash, running multiple times, or running in the background.It's a matter of the program itself.

We understand that this error is caused by a double release of memory.

I don't understand the nature of the problem.Double-openness itself is not a problem.Actually, it continued to be used even though the memory was determined not to be used and released once.After that, it was determined that it would not be used again and the release process took place.

Corrective action is to properly manage memory usage.


2022-09-30 21:53

SAFE_FREE is not a "preventing double-open memory" macro.
If you call SAFE_FREE multiple times, you will call free (NULL) on the second SAFE_FREE.

SAFE_FREE(x);
SAFE_FREE(x);

SAFE_FREE requires the following features:

  • To make it clear that the free pointer is already free, replace the NULL pointer
  • Free only when the specified pointer is not a NULL pointer

Example

#defineSAFE_FREE(ptr){ if(ptr!=NULL)free(ptr); ptr=NULL;} 

上The above example was not actually tried.

As you commented, I looked into free (NULL).

If you do free (NULL), nothing will be done

In conclusion, it is very likely that the questioner's symptom was caused by another cause.
I tried Ubuntu 18.04.5 LTS, but there was no problem.

C99 ( 7 7.20.3.2) says Ifptris a null pointer, no action occur..
GNU 2017-09-15 MALLOC(3) and Ifptris NULL, no operation is performed. are the same.

if(ptr)free(ptr) seems to have a lot of different opinions.

  • Not all processing systems are safe
  • Don't get caught up in old customs
  • Unnecessary code interferes with code reading
  • Reduce the number of overheads calling free*There was a counterargument that the effect was minor and had nothing to do with safety
  • It's a good habit to use pointer variables after checking NULL


2022-09-30 21:53

If you have any answers or tips


© 2024 OneMinuteCode. All rights reserved.