OpenBSD: Malloc leak detection available in -current
undeadly.org
undeadly.org
> 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.
...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.
You are conflating unfreed memory with unreferencable memory.
You can compile large C++ projects in a GB of RAM based netbook with Clang and ZRAM.
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!
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 :)
Just curious how they have changed since RS/6000 days.
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.
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.
It's not that difficult to run addr2line yourself with the information provided, and that's really for the best.
“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), 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.”
Valgrind exists in ports, but it is ancient and broken. It does not play well with various security mitigations.
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”?
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.
With that said, valgrind works great and I like its output, time will tell if I will like the output from this OpenBSD change.
This is entirely untrue, though. Linux is GPL and it gets way more use than any of the pushover-licensed BSDs do.
Also, why use ‘pushover’? OpenBSD has strong principles that they’re willing to give up things for, so implying they’re weak is derogatory and unfair.
I use "pushover" because that's what the FSF uses: <https://www.gnu.org/licenses/license-compatibility.en.html>
> we call them “pushover licenses” because they can't say “no” when one user tries to deny freedom to others.
* "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.
Which in some people's opinion, is no better. Just a different set of handcuffs.
> Some of the software which is fetched and compiled is not as free as we would like, but what can we do.
They could choose to not put such software in their ports tree.
> Meanwhile, Richard has personally made sure that all the official GNU software — including Emacs — compiles and runs on Windows.
There's a big difference between making free software support a non-free system and distributing non-free software.
> Rule 1: You cannot sell your code! Rule 2: You must give it only to me
Straw man. The GPL doesn't have anything even resembling either of those rules.
> You cannot give your code away
This is clearly completely absurd and not required by any free license.
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@.
Now apply these exceptions to user space, and you’ve basically reinvented the LGPL.
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).