Re: debugging a memory leak

2016-05-28 Thread Manuel Bouyer
On Fri, May 20, 2016 at 09:56:42PM +0200, Manuel Bouyer wrote: > Hello, > what tools do we have on NetBSD to find a memory leak in a userland > program (actually OpenCPN - which is a large C++ program with dynamic > libraries and uses dlopen()) ? > > The memory usage of the process is slowy growin

Re: debugging a memory leak

2016-05-23 Thread tlaronde
On Sun, May 22, 2016 at 06:22:29PM -0400, Dan LaBell wrote: > > On May 21, 2016, at 4:10 AM, Manuel Bouyer wrote: > > >On Sat, May 21, 2016 at 08:36:10AM +0200, tlaro...@polynum.com wrote: > >>On Fri, May 20, 2016 at 11:43:11PM +0200, Manuel Bouyer wrote: > >>>On Fri, May 20, 2016 at 02:20:39PM -

Re: debugging a memory leak

2016-05-22 Thread Dan LaBell
On May 21, 2016, at 4:10 AM, Manuel Bouyer wrote: On Sat, May 21, 2016 at 08:36:10AM +0200, tlaro...@polynum.com wrote: On Fri, May 20, 2016 at 11:43:11PM +0200, Manuel Bouyer wrote: On Fri, May 20, 2016 at 02:20:39PM -0600, Swift Griggs wrote: On Fri, 20 May 2016, Manuel Bouyer wrote: what

Re: debugging a memory leak

2016-05-21 Thread Sad Clouds
On Fri, 20 May 2016 21:56:42 +0200 Manuel Bouyer wrote: > Hello, > what tools do we have on NetBSD to find a memory leak in a userland > program (actually OpenCPN - which is a large C++ program with dynamic > libraries and uses dlopen()) ? > > The memory usage of the process is slowy growing, un

Re: debugging a memory leak

2016-05-21 Thread William A. Mahaffey III
On 05/21/16 08:37, Rhialto wrote: On Sat 21 May 2016 at 00:19:49 +, Valery Ushakov wrote: Timo Buhrmester wrote: but it's limited to Linux, Darwin, and Solaris. Last time I checked, FreeBSD also had valgrind working. I wonder how much effort it would be to port it to NetBSD. As far as

Re: debugging a memory leak

2016-05-21 Thread Rhialto
On Sat 21 May 2016 at 00:19:49 +, Valery Ushakov wrote: > Timo Buhrmester wrote: > > > > but it's limited to Linux, Darwin, and Solaris. > > > > Last time I checked, FreeBSD also had valgrind working. I wonder > > how much effort it would be to port it to NetBSD. > > As far as I understand

Re: debugging a memory leak

2016-05-21 Thread tlaronde
On Sat, May 21, 2016 at 10:10:03AM +0200, Manuel Bouyer wrote: > On Sat, May 21, 2016 at 08:36:10AM +0200, tlaro...@polynum.com wrote: > > On Fri, May 20, 2016 at 11:43:11PM +0200, Manuel Bouyer wrote: > > > On Fri, May 20, 2016 at 02:20:39PM -0600, Swift Griggs wrote: > > > > On Fri, 20 May 2016,

Re: debugging a memory leak

2016-05-21 Thread tlaronde
On Fri, May 20, 2016 at 11:43:11PM +0200, Manuel Bouyer wrote: > On Fri, May 20, 2016 at 02:20:39PM -0600, Swift Griggs wrote: > > On Fri, 20 May 2016, Manuel Bouyer wrote: > > > what tools do we have on NetBSD to find a memory leak in a userland > > > program (actually OpenCPN - which is a large

Re: debugging a memory leak

2016-05-21 Thread Manuel Bouyer
On Sat, May 21, 2016 at 08:36:10AM +0200, tlaro...@polynum.com wrote: > On Fri, May 20, 2016 at 11:43:11PM +0200, Manuel Bouyer wrote: > > On Fri, May 20, 2016 at 02:20:39PM -0600, Swift Griggs wrote: > > > On Fri, 20 May 2016, Manuel Bouyer wrote: > > > > what tools do we have on NetBSD to find a

Re: debugging a memory leak

2016-05-21 Thread William A. Mahaffey III
On 05/20/16 15:26, Swift Griggs wrote: On Fri, 20 May 2016, Manuel Bouyer wrote: what tools do we have on NetBSD to find a memory leak in a userland program (actually OpenCPN - which is a large C++ program with dynamic libraries and uses dlopen()) ? Manuel, I'm guessing you are a much better C

Re: debugging a memory leak

2016-05-20 Thread Valery Ushakov
Timo Buhrmester wrote: > > but it's limited to Linux, Darwin, and Solaris. > > Last time I checked, FreeBSD also had valgrind working. I wonder > how much effort it would be to port it to NetBSD. As far as I understand (I had my brushes with valgrind internals) it's mostly the drudgery of, eff

Re: debugging a memory leak

2016-05-20 Thread Swift Griggs
On Fri, 20 May 2016, Manuel Bouyer wrote: > I though ElectricFence would only detect things like use after free or > out of bound access, but not memory leaks ? Hmm, I thought it did. Like if you try to malloc() over a pointer and clobber it before you free()'d the previous one (say in a loop/it

Re: debugging a memory leak

2016-05-20 Thread Manuel Bouyer
On Fri, May 20, 2016 at 10:29:02PM +0200, Timo Buhrmester wrote: > > but it's limited to Linux, Darwin, and Solaris. > Last time I checked, FreeBSD also had valgrind working. I wonder how > much effort it would be to port it to NetBSD. google found some talks about it for NetBSD but it seems the

Re: debugging a memory leak

2016-05-20 Thread Manuel Bouyer
On Fri, May 20, 2016 at 02:20:39PM -0600, Swift Griggs wrote: > On Fri, 20 May 2016, Manuel Bouyer wrote: > > what tools do we have on NetBSD to find a memory leak in a userland > > program (actually OpenCPN - which is a large C++ program with dynamic > > libraries and uses dlopen()) ? > > Manue

Re: debugging a memory leak

2016-05-20 Thread Timo Buhrmester
> but it's limited to Linux, Darwin, and Solaris. Last time I checked, FreeBSD also had valgrind working. I wonder how much effort it would be to port it to NetBSD.

Re: debugging a memory leak

2016-05-20 Thread Swift Griggs
On Fri, 20 May 2016, Manuel Bouyer wrote: > what tools do we have on NetBSD to find a memory leak in a userland > program (actually OpenCPN - which is a large C++ program with dynamic > libraries and uses dlopen()) ? Manuel, I'm guessing you are a much better C programmer than I, but I can rela

debugging a memory leak

2016-05-20 Thread Manuel Bouyer
Hello, what tools do we have on NetBSD to find a memory leak in a userland program (actually OpenCPN - which is a large C++ program with dynamic libraries and uses dlopen()) ? The memory usage of the process is slowy growing, until the systems gets out of ram/swap and kills it (on my evbarm which