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

21–30 of 61 posts

Re: OpenBSD: Malloc leak detection available in -current

#21

Post by charcircuit »

notaplumber1 wrote: post #18
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, p…

Just link to the code instead of executing it as a separate binary

Re: OpenBSD: Malloc leak detection available in -current

#22

Post by jmclnx »

pjmlp wrote: post #19
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.

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

Re: OpenBSD: Malloc leak detection available in -current

#23

Post by josephcsible »

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…

> it is a condition that is typically unacceptable for commercial use of software

This is entirely untrue, though. Linux is GPL and it gets way more use than any of the pushover-licensed BSDs do.

Re: OpenBSD: Malloc leak detection available in -current

#24

Post by colonwqbang »

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.

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

Re: OpenBSD: Malloc leak detection available in -current

#25

Post by notaplumber1 »

charcircuit wrote: post #21
notaplumber1 wrote: post #18

Earlier quoted context omitted.

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, p…

Just link to the code instead of executing it as a separate binary

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

Re: OpenBSD: Malloc leak detection available in -current

#26

Post by sbuk »

josephcsible wrote: post #23
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…

> it is a condition that is typically unacceptable for commercial use of software This is entirely untrue, though. Linux is GPL and it gets way more use than any of the pushover-licensed BSDs do.

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.

Re: OpenBSD: Malloc leak detection available in -current

#27

Post by Someone »

josephcsible wrote: post #23
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…

> it is a condition that is typically unacceptable for commercial use of software This is entirely untrue, though. Linux is GPL and it gets way more use than any of the pushover-licensed BSDs do.

IMO, even if they hadn’t included ’typically’ to weaken their claim, one counterexample doesn’t make that _entirely_ untrue.

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.

Re: OpenBSD: Malloc leak detection available in -current

#28

Post by ninjin »

sbuk wrote: post #26
josephcsible wrote: post #23

Earlier quoted context omitted.

> it is a condition that is typically unacceptable for commercial use of software This is entirely untrue, though. Linux is GPL and it gets way more use than any of the pushover-licensed BSDs do.

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.

Re: OpenBSD: Malloc leak detection available in -current

#29

Post by miohtama »

colonwqbang wrote: post #24
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.

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

To work around leaks, just don’t run your GNU programs for very long (:

Re: OpenBSD: Malloc leak detection available in -current

#30

Post by josephcsible »

Someone wrote: post #27
josephcsible wrote: post #23

Earlier quoted context omitted.

> it is a condition that is typically unacceptable for commercial use of software This is entirely untrue, though. Linux is GPL and it gets way more use than any of the pushover-licensed BSDs do.

IMO, even if they hadn’t included ’typically’ to weaken their claim, one counterexample doesn’t make that _entirely_ untrue. 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 feel like Linux is so incredibly popular that it does make it untrue, similar to the punchline of https://what-if.xkcd.com/49/>.

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.

Post reply on HN