3 ms·

This not bulletproof method to handle memory leaks as it still keeps all allocations. It simply keeps a list of all allocations but doesn't address the core iss

This not bulletproof method to handle memory leaks as it still keeps all allocations. It simply keeps a list of all allocations but doesn't address the core issue of unnecessary memory consumption if free is not called. But the more pressing problem is that this implementation is not thread safe. Concurrent accesses to the bigbucket list in a multi-threaded programs can easily lead to race conditions

mysterydip 3y ago
While I'm sure it would bring its own problems, could you just stick a semaphore or similar around the function?
- bluish29 3y ago
  Yes, but it will not work in a generic case because you have to handle the situations of deadlocks (i.e recursive mutexes for nested locking ..etc). Also you will introduce more problems of creating performance deadlocks. There will not be out of box solutions to all these. Once you start considering solving case on its own then this does not provide out of box solution as the original premise.
  - akoboldfrying 3y ago
    I think the only way this design could deadlock is if a signal handler calls malloc() -- specifically, if the interrupted code on that CPU thread was partway through a malloc() call of its own, having locked the mutex but not yet unlocked it. In any other scenario, if some execution thread reaches the point where it returns from calling lock() on the mutex guarding malloc(), it must eventually reach the call to unlock().
- deleted 3y ago
  [deleted]
- akoboldfrying 3y ago
  We're deep in a ridiculous scenario here, but the answer is that, yes, this would result in a safe program, provided that it never calls malloc() from a signal handler (since that would deadlock if the interrupted code had already grabbed the lock/mutex/semaphore/whatever). In any other scenario, if some execution thread reaches the point where it returns from calling lock() on the mutex guarding malloc(), it must eventually reach the call to unlock().

mysterydip 3y ago

While I'm sure it would bring its own problems, could you just stick a semaphore or similar around the function?

bluish29 3y ago
Yes, but it will not work in a generic case because you have to handle the situations of deadlocks (i.e recursive mutexes for nested locking ..etc). Also you will introduce more problems of creating performance deadlocks. There will not be out of box solutions to all these. Once you start considering solving case on its own then this does not provide out of box solution as the original premise.
- akoboldfrying 3y ago
  I think the only way this design could deadlock is if a signal handler calls malloc() -- specifically, if the interrupted code on that CPU thread was partway through a malloc() call of its own, having locked the mutex but not yet unlocked it. In any other scenario, if some execution thread reaches the point where it returns from calling lock() on the mutex guarding malloc(), it must eventually reach the call to unlock().
deleted 3y ago
[deleted]
akoboldfrying 3y ago
We're deep in a ridiculous scenario here, but the answer is that, yes, this would result in a safe program, provided that it never calls malloc() from a signal handler (since that would deadlock if the interrupted code had already grabbed the lock/mutex/semaphore/whatever). In any other scenario, if some execution thread reaches the point where it returns from calling lock() on the mutex guarding malloc(), it must eventually reach the call to unlock().