> 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.
> 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.
Well yeah if your program does something and then terminates then memory leaks are not an issue.
If your process is a server or a daemon or something then restarting each instance every N hours is a nice backstop but memory leaks are still a frightening spanner in the works!
This 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 :)
Could 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.
> 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.
OpenBSD 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.
Are 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.
I 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?
You 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.
In addition to what others said, Valgrind is GPL-licensed. That conflicts with the OpenBSD copyright policy (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.”
“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.”
OpenBSD begrudgingly made an exception for LLVM/Clang, after vocal opposition to the re-licencing. It currently uses LLVM/Clang 13 and has been making progress towards 15. Licensing is not the problem here. Most of the sanitizers are simply not enabled in the version shipped in base, and require runtime libraries that have not been ported to OpenBSD.
Valgrind exists in ports, but it is ancient and broken. It does not play well with various security mitigations.
> OpenBSD begrudgingly made an exception for LLVM/Clang […] Licensing is not the problem here
If it isn’t a problem, why do you say “begrudgingly”?
I think they are pragmatic but also do find it a problem. Why else would they say “source code published under version 2 of the Apache license is subject to additional restrictions and cannot be included into OpenBSD”?
I didn't say it wasn't a problem. I said it was not the problem here. Important distinction.
Licensing is not the reason for the sanitizers not being enabled in the default build, a lot of stuff isn't. If it were supported, it would probably be delegated to the ports version, along with the analyzer, additional llvm tools, cross-compiling, etc.
I think that’s what your parent is saying too. The last non-Apache-2-licensed version of the Apache HTTP server was version 1.3.x, and because the OpenBSD project did not accept the Apache 2 license, they forked the Apache HTTP server’s 1.3.x code base.
It's not coincidental. It was early in the Apache 2.0 lifecycle that the Apache License 2.0 came about (google says 2.0.49). OpenBSD's continued maintenance of a 1.x fork from 2004-2011 or so was mainly about licensing.
The point that Theo de Raadt is making is that this line of thinking is wrong*. Most of the FSF/GPL advocates never seem to look at the why's around people disliking their approach. See https://lkml.org/lkml/2007/9/1/102 as an example. OpenBSD helped the Linux project dual license the ath5k driver. They were thanked by GPL advocates illegally trying to strip the BSD license after the fact. Leaves a bad taste, and one that many of us won't forget. You can have your forced freedom.
* "GPL fans said the great problem we would face is that companies would take our BSD code, modify it, and not give back. Nope—the great problem we face is that people would wrap the GPL around our code, and lock us out in the same way that these supposed companies would lock us out. Just like the Linux community, we have many companies giving us code back, all the time.
But once the code is GPL'd, we cannot get it back."
EDIT: The pejoratives are why the FSF message gets lost on an awful lot of people. I admire what they are trying to achieve, the manner in which they go about it makes me not want to engage.
Theo de Raadt is the one who's wrong. When code goes closed source, you're locked out and can't have it at all anymore. When it goes GPL, you can still have it just by going GPL yourself.
“This is madness!
He has lost his mind!
This defies the first law of free trade.
Rule zero came before this rule one.
Freedom means you cannot dictate to anyone.” (emphasis mine)
I provided a reference for a portion of lyrics that fairly elegantly summarised the BSD position on freedom – that is it. Besides, it is a song and obviously it will take artistic liberties compared to an essay.
If you want to argue minutia related to things on that page other than the tiny lyric snippet, it is probably better that you send an e-mail to misc@.
They're describing libraries. By 'Linux', I'm assuming that you're referring to the OS distributions and not the kernel on it's own. And please drop the pejoratives.
There is seemingly a movement or line of thought that blames the success of “big tech” on permissive licenses. You do not see it as much on Hacker News, but it certainly has spread across IRC and many other forums. What is even odder is that a subset of it uses alt-right terminology to refer to both permissive licenses and their proponents. It is all very weird to experience as someone that entered the FLOSS community in the early 00s. Not to mention having had a personal conversation with rms bemoaning the license schisms and him explicitly expressing gratitude for the BSDs contributing to the larger FLOSS movement.
Both 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).
This is available by default and integrates with existing tools (notably ktrace), making it easier to detect memory leaks on all platforms OpenBSD supports.
> 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-a...
I think many GNU tools just never free any memory.
For example, GCC : https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66339
-- edit: added GCC as example.