8 ms·
OpenBSD: Malloc leak detection available in -current
- saagarjha 4y agoNeat! Although, I'm curious why the tool doesn't just run addr2line for you?
- notaplumber1 4y agoAre you asking why doesn't it execv(2) addr2line deep within the libc malloc implementation? Because calling execv(2) within libraries is frowned upon.. ;-) The leak report is being generated internally by malloc. It is then logged via utrace(2) when a process is traced through ktrace(1). The kdump utility simply dumps the report, strvis(3) escaping any potentially unsafe characters. As this is untrusted user data, passing it as the input/args to another command is unwise. Also kdump(1) uses pledge(2) and cannot execute commands.
- charcircuit 4y agoJust link to the code instead of executing it as a separate binary
- notaplumber1 4y agoI'm pretty sure parsing ELF binaries is out of scope for kdump(1), sorry, but I don't think that's going to happen. It's not that difficult to run addr2line yourself with the information provided, and that's really for the best.
- charcircuit 4y agoYou are arguing for a worse UX because of an arbitrary reason. Just link against the code in addr2line. Providing a good UX should always be in scope for a project.
- sigjuice 4y agoHow does one "just link against the code in addr2line" ?
- charcircuit 4y agoYou rename them main symbol to something else then you just call it like any other library.
- sigjuice 4y agoaddr2line is unlikely to be a trivial self-contained program without dependencies.
- charcircuit 4y agoThen link to those dependencies.
- sigjuice 4y agoUnnecessary. Most people's hands will be able to type up the required shell one-liner to do this.
- tedunangst 4y agoWhy would openbsd want to taint kdump with GPL code?
- charcircuit 4y agoThen find or write an alternative. Asking people to run a command to see the file and line number is a joke.
- yakubin 4y agoLLVM provides llvm-addr2line and llvm-symbolizer. Of course I understand not wanting to link with LLVM code, even when the licence is ok. :)
- saagarjha 4y agoI guess I’m confused what’s printing the output here. On other OSes typically things like this are implemented by malloc recording the addresses and whatever parses the report later doing the symbolication when displaying it. I guess kdump just dumps the report but is there no porcelain that takes the kdump data and cleans it up a bit more for human consumption?
- bruce343434 4y agoWhy duplicate the efforts of valgrind and address sanitizer?
- irdc 4y agoThis is available by default and integrates with existing tools (notably ktrace), making it easier to detect memory leaks on all platforms OpenBSD supports.
- avar 4y agoBoth of those are very useful, but slow, especially valgrind. I don't know OpenBSD, but presumably this is analogous to glibc's relatively faster memory sanity checking. For GCC and clang you'd also want LSAN for this, not ASAN. ASAN is more accurate for edge cases, but much slower. "Slow" here means that even for development the runtime can be prohibitively expensive. E.g. I regularly run git's test suite, optimized/LSAN/ASAN/valgrind runtime is on the order of 3m/15m/30m/24 hours. The basic glibc sanity checking only adds a minute or two to the optimized run. An advantage of any malloc based detection is also that you can run it on any existing binary. Whereas the likes of LSAN and ASAN require a custom debugging build (or to have that tracing overhead present in your production build).
- Someone 4y agoIn addition to what others said, Valgrind is GPL-licensed. That conflicts with the OpenBSD copyright policy (https://www.openbsd.org/policy.html https://www.openbsd.org/policy.html), which says: “The GNU Public License and licenses modeled on it impose the restriction that source code must be distributed or made available for all works that are derivatives of the GNU copyrighted code. While this may superficially look like a noble strategy, it is a condition that is typically unacceptable for commercial use of software. So in practice, it usually ends up hindering free sharing and reuse of code and ideas rather than encouraging it. As a consequence, no additional software bound by the GPL terms will be considered for inclusion into the OpenBSD base system.” As to clang’s Address Sanitizer, that’s under the Apache License v2.0 with LLVM Exceptions (https://github.com/google/sanitizers/blob/master/LICENSE.TXT https://github.com/google/sanitizers/blob/master/LICENSE.TXT), of which the same page says: “The original Apache license was similar to the Berkeley license, but source code published under version 2 of the Apache license is subject to additional restrictions and cannot be included into OpenBSD. In particular, if you use code under the Apache 2 license, some of your rights will terminate if you claim in court that the code violates a patent.”
- anthk 4y agoOpenBSD had malloc.conf settings to set more strict settings. For instance, programs like detox might crash on complex input. I wonder how could OpenBSD work with both enabled.
- jmclnx 4y agoThis is great news to me, it is the one think I was hoping for. I use OpenBSD to test objects I create and testing there discovered issues that Linux and AIX happily ignored. But I used valgrind on Linux to look for leaks. With this I can now test for all "my issues" on OpenBSD :)
- pjmlp 4y agoDid you used xlC tooling on Aix? Just curious how they have changed since RS/6000 days.
- jmclnx 4y agoYes, but I doubt it changed that much. It did work better for me than gcc on AIX. But I expect the admins messed up gcc when the installed it.
- nighmi 4y agoCould you share more about how nd why you use AIX? How is it in production? Im very interested in corp Unixes but have never met anyone still using one, alrhough new features keep getting added.
- j16sdiz 4y agoTo quota GNU libc manual: > There is no point in freeing blocks at the end of a program, because all of the program’s space is given back to the system when the process terminates. https://www.gnu.org/software/libc/manual/html_node/Freeing-after-Malloc.html https://www.gnu.org/software/libc/manual/html_node/Freeing-a... I think many GNU tools just never free any memory. For example, GCC : https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66339 https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66339 -- edit: added GCC as example.
- baggy_trough 4y agoOne point would be to be able to detect memory leaks with tools.
- matvore 4y agoThe last time I used a leak finder, a memory allocation which still has a ptr to it is not a leak. You are conflating unfreed memory with unreferencable memory.
- TazeTSchnitzel 4y agoReachability is one strategy for detecting leaks but it's not the only one. Checking for unfreed memory is easier to implement.
- anthk 4y agoOn GCC, the memory usage on compiling C++ vs Clang can be night and day. You can compile large C++ projects in a GB of RAM based netbook with Clang and ZRAM.
- colonwqbang 4y ago> There is no point in freeing blocks at the end of a program ...unless you are trying to find memory leaks in your program. In that case it would be very helpful if the program, and the libraries it uses, were written to actively free all allocated memory. > I think many GNU tools just never free any memory It is absolutely true that some GNU software (including libraries like glib) allocate memory that they never intend to free. This causes leak analysis of programs that link with these libraries to be more painful than necessary.
- Karellen 4y ago> The null "f" values (call sites) are due to the sampling nature of small allocations. Recording all call sites of all potential leaks introduces too much overhead. Hmmm.... "too much" feels like a trade-off or value judgement that won't apply to all cases, and some people would probably like to be able to take the performance hit in exchange for a complete trace. Seems a bit odd that that's not even available as an option, as well as the current behaviour.