3 ms·

Really? I've found the devs who say this are just having trouble understanding the results these tools put out. No offence intended but do you think that coul

Really? I've found the devs who say this are just having trouble understanding the results these tools put out. No offence intended but do you think that could be the case?

JoeAltmaier 11y ago
Nope. Been doing this 20 years, tried them all. The biggest mistake is, they report all memory allocations as 'leaks'. Instead of just repeated allocations without corresponding freeing. So you get 1,000 reports of which 1 or 2 are really problems. Then they like to carp about exactly how the memory was freed, which primitive etc. Which can matter when multiple heap disciplines are in use. But when they aren't its just more noise. I remember an embedded fibre channel router we did, 16 processors and 100's of server message handlers. We tried a heap validation tool of some sort (valgrind?) and after a week of struggle we found exactly one sort-of problem ( a small leak ) out of the thousands of false alarms. Definitely not worth the effort.
- kazinator 11y ago
  Valgrind's leak detector separately reports: - still reachable allocated blocks - possibly leaked blocks: block reachable only via pointers to their interior, not to their base address - definitely leaked blocks: blocks not reachable by any pointer in the program image. Even the simplest tools like dmalloc do not report all allocations ever performed as leaks (even ones that have been freed). The simple tools report the still-in-use blocks, regardless of whether they are reachable or not. That can be "good enough". And anyway, sometimes blocks that are still reachable are de facto leaks. Programs can have "semantic leaks" whereby some dynamic set data structure keeps growing and growing as processing marches on. For instance, a global hash table from which nothing is removed even though the entries have ceased to be relevant and the table is the only thing which refers to them. (Someone forgot to make the hash table a weak hash).
- jcoffland 11y ago
  This is exactly what I'm talking about. You can enable options to filter though these warnings. Too many devs get overwhelmed by the output and give up early. It takes some practice to use correctly but tools like valgrind are invaluable. Also, if you are ignoring warnings about using the wrong deallocator in C++ then you are making a big mistake. Your code may work but this causes nasty bugs. E.g. if you allocate with 'new []' and then deallocate with plain old 'delete' or worse 'free()'.
  - JoeAltmaier 11y ago
    I understand all that. In the end, I've experienced no benefit from these tools. The example about new[]/delete; is a good one. That is important only if the element has a ctor/dtor. Yet the tools flag simple scalar arrays as well - pointlessly adding to the noise.
- deleted 11y ago
  [deleted]

Really? I've found the devs who say this are just having trouble understanding the results these tools put out. No offence intended but do you think that could be the case?

JoeAltmaier 11y ago

Nope. Been doing this 20 years, tried them all. The biggest mistake is, they report all memory allocations as 'leaks'. Instead of just repeated allocations without corresponding freeing. So you get 1,000 reports of which 1 or 2 are really problems. Then they like to carp about exactly how the memory was freed, which primitive etc. Which can matter when multiple heap disciplines are in use. But when they aren't its just more noise. I remember an embedded fibre channel router we did, 16 processors and 100's of server message handlers. We tried a heap validation tool of some sort (valgrind?) and after a week of struggle we found exactly one sort-of problem ( a small leak ) out of the thousands of false alarms. Definitely not worth the effort.

kazinator 11y ago
Valgrind's leak detector separately reports: - still reachable allocated blocks - possibly leaked blocks: block reachable only via pointers to their interior, not to their base address - definitely leaked blocks: blocks not reachable by any pointer in the program image. Even the simplest tools like dmalloc do not report all allocations ever performed as leaks (even ones that have been freed). The simple tools report the still-in-use blocks, regardless of whether they are reachable or not. That can be "good enough". And anyway, sometimes blocks that are still reachable are de facto leaks. Programs can have "semantic leaks" whereby some dynamic set data structure keeps growing and growing as processing marches on. For instance, a global hash table from which nothing is removed even though the entries have ceased to be relevant and the table is the only thing which refers to them. (Someone forgot to make the hash table a weak hash).
jcoffland 11y ago
This is exactly what I'm talking about. You can enable options to filter though these warnings. Too many devs get overwhelmed by the output and give up early. It takes some practice to use correctly but tools like valgrind are invaluable. Also, if you are ignoring warnings about using the wrong deallocator in C++ then you are making a big mistake. Your code may work but this causes nasty bugs. E.g. if you allocate with 'new []' and then deallocate with plain old 'delete' or worse 'free()'.
- JoeAltmaier 11y ago
  I understand all that. In the end, I've experienced no benefit from these tools. The example about new[]/delete; is a good one. That is important only if the element has a ctor/dtor. Yet the tools flag simple scalar arrays as well - pointlessly adding to the noise.
deleted 11y ago
[deleted]