Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

OpenBSD: Malloc leak detection available in -current

undeadly.org

Post reply on HN
Print view View original

11–20 of 61 posts

Re: OpenBSD: Malloc leak detection available in -current

#11

Post by asveikau »

alberth wrote: post #9
Someone wrote: post #6

Earlier quoted context omitted.

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 c…

I had no idea that OpenBSD didn't accept Apache 2 code https://www.openbsd.org/policy.html

They maintained apache 1.x in base for a long time. For a small number of releases they switched to nginx and then i think they wrote their own.

Re: OpenBSD: Malloc leak detection available in -current

#12

Post by whydoyoucare »

asveikau wrote: post #11
alberth wrote: post #9

Earlier quoted context omitted.

I had no idea that OpenBSD didn't accept Apache 2 code https://www.openbsd.org/policy.html

They maintained apache 1.x in base for a long time. For a small number of releases they switched to nginx and then i think they wrote their own.

Yes, httpd. https://man.openbsd.org/httpd.8

Re: OpenBSD: Malloc leak detection available in -current

#13

Post by baggy_trough »

j16sdiz wrote: post #10

To 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-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.

One point would be to be able to detect memory leaks with tools.

Re: OpenBSD: Malloc leak detection available in -current

#14

Post by matvore »

j16sdiz wrote: post #10

To 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-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.

The 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.

Re: OpenBSD: Malloc leak detection available in -current

#16

Post by Karellen »

> 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.

Re: OpenBSD: Malloc leak detection available in -current

#17

Post by anthk »

j16sdiz wrote: post #10

To 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-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.

On 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.

Re: OpenBSD: Malloc leak detection available in -current

#18

Post by notaplumber1 »

saagarjha wrote: post #15

Neat! Although, I'm curious why the tool doesn't just run addr2line for you?

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.

Re: OpenBSD: Malloc leak detection available in -current

#19

Post by pjmlp »

jmclnx wrote: post #7

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 :)

Did you used xlC tooling on Aix?

Just curious how they have changed since RS/6000 days.

Re: OpenBSD: Malloc leak detection available in -current

#20

Post by notaplumber1 »

Someone wrote: post #6
bruce343434 wrote: post #2

Why duplicate the efforts of valgrind and address sanitizer?

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 c…

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.

Post reply on HN