https://bugs.kde.org/show_bug.cgi?id=392855
--- Comment #12 from Philippe Waroquiers <philippe.waroqui...@skynet.be> --- (In reply to Tom Hughes from comment #10) > I don't believe we have ever attempted to suppress memory allocations done > by the system libraries - you may have been lucky in not seeing any but I > don't believe it has ever been our policy to suppress them. > > In fact I don't think we've ever even had a suppression type that would stop > memory allocations being counted in those statistics - leaks can be > suppressed by they are still counted in the statistics of the amount of > memory allocated. > > The counts are the counts of allocations done by the whole of the program > including all libraries that it uses and I'm not sure why anybody would find > that surprising, or find the idea that the C library does some allocations > internally hard to understand. I completely agree with Tom. In fact, if we would want to fix this case, we would face 2 problems: 1. define for which libraries we need to 'hide' the malloc This report speaks about 'printf', but we have plenty of other 'system libs' we might want to consider. For example, gethostbyname will maybe also allocate some memory and we could ask to hide it. Similarly, maybe pthread_attr_init could allocate some memory, and we could similarly have to hide it. And then we could do a similar reasoning for gtk library, Qt, gnome, kde, ... We will then have zillions of malloc-ed objects that will be 'hidden' in big programs. 2. what to do when a library does a malloc and one way or another, we need to mention this allocated memory e.g. in an error msg. Or we just have to report the amount of memory currently allocated by the program ? I do not see how we could properly define a reasonable semantic for the above. Users must be aware that even in simple programs, a lot of things are happening inside explicitly or implicitly linked libraries. I understand the wish to hide this for 'hello world' programs, but that will give major difficulties for non trivial programs. So, in summary: this is not a bug, as there is no way to improve this without introducing significant implementation and conceptual difficulties, a lot worse than the initial difficulty. -- You are receiving this mail because: You are watching all bug changes.
