Is there a way to determine if free() would fail if ever called on a certain memory block pointer?
I have the following situation: a thread having access to a shared resource fails whilst it may have been in the state of freeing the said resource. Now I need to devise a safe way to clean-up this shared resource.
Of course I have assigned ownership of the resource for the normal case but what about the aforementioned limit case?
UPDATED: If I use additional synchronizing mechanisms it only makes more cleaning up to do and might involved additional limit conditions. I’d like to limit/avoid those if possible.
Resolution: I finally settled on performing re-factoring. Thanks to all contributors. You guys rock!
I’ve seen all kinds of attempts, including this one:
Not only does dereferencing a type punned pointer break various platforms, ‘plugging this example in’ can only work if you initialize, free and re-initialize every single pointer in every single existing function (compiled libs included) and work with a C library that does the same.
Then, deal with optimization AND lock free thread safe issues. BAH!
In short, if you can’t keep track of what you have allocated in a single function, its time to re factor that function. Do that enough .. and you’ll find that the need for a safer free() quickly goes away. Valgrind is your friend if working on a platform that it supports. According to your tags, it really is your friend 🙂
Or, use a malloc() that sports garbage collection at your own expense, depending on how you allocate things and get rid of free() altogether. After that, debugging becomes almost terminally interesting.
Hopefully, you are off to re-factor? While you appear to be having an issue (also) with mutual exclusion, it just leads back to re-factoring. I.e, let the line before free() block, or fail when trying to get a lock .. and set freed pointers to NULL in the thread that has the lock, at least in structures that you implement.