FWIW - there's lots of statistics and some dtrace scripts + output here.
So for those knowlegable in this area, this forum thread is well worth
your time.
Adrian
On 21 August 2012 07:42, Remme wrote:
> Hi All,
>
> Please help to solve a kernel memory leak problem.
> After fe
Hi All,
Please help to solve a kernel memory leak problem.
After few weeks searching forums and googling any help is welcome.
Here is the problem description:
We are installed the latest 9.0 FreeBSD with all recent patches.
Ports tree is also up to date.
Host running a nginx, php-fpm, memcached
On Sat, 16 May 2009 20:24:09 +0200 Marius Nünnerich wrote:
>> http://freshmeat.net/projects/lmdbg
>>
>> This is a small memory leak debugger. It does not provide all functionality
>> you can find in more sophisticated tools but is lightweight, portable and
>&
MG> }
MG> return 0;
MG> }
MG> During the run the program's virtual memory usage constantly grows. The
growth
MG> is observed only when n != m. When running the program with uncommented
MG> sleep() and observing the number of threads with
{}
> >>
> >> }
> >>
> >> return 0;
> >> }
> >>
> >> During the run the program's virtual memory usage constantly grows. The
> growth
> >> is observed only when n != m. When runnin
+) {}
> >>
> >>}
> >>
> >>return 0;
> >> }
> >>
> >> During the run the program's virtual memory usage constantly grows. The
> >> growth is observed only when n != m. When running the program with
s. The
>> growth
>> is observed only when n != m. When running the program with uncommented
>> sleep() and observing the number of threads with 'top -H' I see in turn 2
>> or 4
>> threads. So it looks like memory leak when thread is removed. Should I
On 2009-05-15 14:48, Marius Nünnerich wrote:
Anybody knows good tools how to investigate this?
Valgrind?
___
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "freebsd-h
gt; }
>
> During the run the program's virtual memory usage constantly grows. The growth
> is observed only when n != m. When running the program with uncommented
> sleep() and observing the number of threads with 'top -H' I see in turn 2 or 4
> threads. So it looks
rogram with uncommented
sleep() and observing the number of threads with 'top -H' I see in turn 2 or 4
threads. So it looks like memory leak when thread is removed. Should I fill
PR?
--
Mikolaj Golub
___
freebsd-hackers@freebsd.org mailing list
htt
On Wed, 2006-Aug-02 15:22:26 +1000, Q wrote:
>I have made some more progress on identifying this problem. If I drop
>to single user mode, and then unmount the volume that houses the
>database and the raw data, the accumulated memory is released. When
>it did this earlier it dropping from 870M
On 01/08/2006, at 3:10 PM, Q wrote:
I was wondering if someone could help point me in the direction of
how to go about trying to resolve what I assume to be a memory leak
in FreeBSD 6.x.
I have made some more progress on identifying this problem. If I drop
to single user mode, and then
(Resent: Apologies if this is a duplicate)
Hi,
I was wondering if someone could help point me in the direction of
how to go about trying to resolve what I assume to be a memory leak
in FreeBSD 6.x.
I have two database servers, one running 6.0 the other 6.1, both are
running PostgreSQL
Hello,
I'm having trouble with a WARP (http://www.pcengines.ch/wrap.htm) board
running m0n0wall v1.21 (stripped down FreeBSD 4.11-RELEASE-p13). It's serving
as an internet gateway and the problem is, that after some time it starts
blocking traffic and doesn't do NAT anymore. The box is handling
Nate Nielsen wrote:
> I'm experiencing a memory leak in the net80211 code. I have two atheros
> 5213-A cards on two embedded systems running FreeBSD 6.0. They are setup
> as IBSS (adhoc) stations. After roughly 15 seconds of ~14Mbps TCP
> traffic (single stream) I promptly
> We have this section of code:
> 1. new_body = api_filter(origin_resp_body,origin_resp_body_len);
> 2. origin_resp_body_len = new_body->length;
> 3. origin_resp_body = new_body->data;
>
> I figure that the memory leak is occuring with origin_resp_body being
&g
Hi
I have the netapp code they release for icap server. Ive ported it to FreeBSD.
And I have found
there is a memory leak in the code itself. Ive tried contacting netapp
directly, but no reply.
Their code can be found at : http://www.i-cap.org/spec/icap-server10.tar.gz
Ive been trying to fix
On Tue, Mar 15, 2005 at 09:42:07PM +0100, Marc Olzheim wrote:
> > Thanks. Could someone generate the patch as I dont have the latest
> > FreeBSD source checked out.
>
> Hmm, there seem to be more possible leaks, as the code has been
> literally copied from /usr/src/gnu/usr.bin/gzip/, including the
On Tue, Mar 15, 2005 at 12:15:11PM -0800, [EMAIL PROTECTED] wrote:
> Thanks. Could someone generate the patch as I dont have the latest
> FreeBSD source checked out.
Hmm, there seem to be more possible leaks, as the code has been
literally copied from /usr/src/gnu/usr.bin/gzip/, including the defi
Subject: Re: memory leak in inflate.c
On Mon, Mar 14, 2005 at 09:43:52PM +0100, Marco Molteni wrote:
> On Mon, 14 Mar 2005 <[EMAIL PROTECTED]> wrote:
> > Hi, I am trying to debug a memory leak in executing g
On Mon, Mar 14, 2005 at 09:43:52PM +0100, Marco Molteni wrote:
> On Mon, 14 Mar 2005 <[EMAIL PROTECTED]> wrote:
> > Hi, I am trying to debug a memory leak in executing gzipped binaries
^^
> > when the param
On Mon, 14 Mar 2005 <[EMAIL PROTECTED]> wrote:
> Hi, I am trying to debug a memory leak in executing gzipped binaries
> when the parameter list is too long. The function in question is
> inflate_dynamic().
>
> /* decompress until an end-of-block code */
>
Hi, I am trying to debug a memory leak in executing gzipped binaries when the
parameter list is too long. The function in question is inflate_dynamic().
/* decompress until an end-of-block code */
if (inflate_codes(glbl, tl, td, bl, bd))
return 1
On Thu, 24 Feb 2005, Seán C. Farley wrote:
Here are the two versions I have written to stop the memory leak.
Old (complex): http://www.farley.org/freebsd/tmp/setenv-1.tar.bz2
New (simple): http://www.farley.org/freebsd/tmp/setenv-2.tar.bz2
Also, you may find an uncompressed view of the two tar
itten a new version that makes copies
of all variables within the environment upon the first run of setenv().
Here are the two versions I have written to stop the memory leak.
Old (complex): http://www.farley.org/freebsd/tmp/setenv-1.tar.bz2
New (simple): http://www.farley.org/freebsd/tmp/setenv-2.t
Seán C. Farley <[EMAIL PROTECTED]> writes:
> How does this version look?
Needlessly complicated. I'd just copy the entire environment into
malloc()ed space the first time setenv() or putenv() is called.
DES
--
Dag-Erling Smørgrav - [EMAIL PROTECTED]
_
ir man pages.
The latest PR on this (two PR's mentioned in it are closed):
http://www.freebsd.org/cgi/query-pr.cgi?pr=misc/19406
They were closed for a reason. Read their audit trails.
I could find no apparent reason for continuing to allow for the
memory leak. The only reason given to allow it wa
PR on this (two PR's mentioned in it are closed):
> http://www.freebsd.org/cgi/query-pr.cgi?pr=misc/19406
They were closed for a reason. Read their audit trails.
> I could find no apparent reason for continuing to allow for the memory
> leak. The only reason given to allow it was to p
On Tue, 2005-Feb-22 22:01:12 -0600, Seán C. Farley wrote:
>The latest PR on this (two PR's mentioned in it are closed):
>http://www.freebsd.org/cgi/query-pr.cgi?pr=misc/19406
...
>Here is a test program along with a patch to stop the leak:
>http://www.farley.org/freebsd/tmp/setenv.tar.bz2
The diff
g/cgi/query-pr.cgi?pr=misc/19406
I could find no apparent reason for continuing to allow for the memory
leak. The only reason given to allow it was to permit programs to
continue to use the environment variable retrieved by setenv() after the
program had reset or deleted it.
If a program can be as
On Wed, Feb 16, 2005 at 12:16:26PM +0100, Dag-Erling Smørgrav wrote:
> [EMAIL PROTECTED] ~/src/gai% cat gai.c
> #include
> #include
> #include
> #include
>
> int
> main(void)
> {
> struct addrinfo hint, *res;
>
> memset(&hint, 0, sizeof(hint));
> hint.ai_family = AF_IN
[EMAIL PROTECTED] ~/src/gai% cat gai.c
#include
#include
#include
#include
int
main(void)
{
struct addrinfo hint, *res;
memset(&hint, 0, sizeof(hint));
hint.ai_family = AF_INET;
hint.ai_socktype = SOCK_STREAM;
hint.ai_protocol = 0;
if (getaddrin
Brian Feldman <[EMAIL PROTECTED]> writes:
> http://green.homeunix.org/~green/boehm-gc.diffs>
have you sent this to the port maintainer (nobutaka@)?
DES
--
Dag-Erling Smørgrav - [EMAIL PROTECTED]
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.o
On Sat, May 22, 2004 at 10:30:42PM -0600, M. Warner Losh wrote:
> Any suggestions for leak detectors that work in real-time or in
> response to some external signal? In a threaded application would be
> ideal.
>
> I've hacked malloc to add the stack traceback to the utrace info
> that's output by
er <[EMAIL PROTECTED]>
To: Cole <[EMAIL PROTECTED]>
Cc: [EMAIL PROTECTED]
Cc: [EMAIL PROTECTED]
Subject: Looking for a ports committer for valgrind (Re: Memory Leak)
> I just wanted to know what programs any of you have used to
> track down a memory leak in your programs?
Daniel O'Connor wrote:
> There is valgrind..
> http://www.rabson.org/#valgrind
>
> I thought it was in ports but I can't see it.
Hi,
as I pointed out in another message of this thread, the port is ready
and waiting for a committer.
Simon
signature.asc
Description: Digital signature
In message: <[EMAIL PROTECTED]>
"Daniel O'Connor" <[EMAIL PROTECTED]> writes:
: -BEGIN PGP SIGNED MESSAGE-
: Hash: SHA1
:
: On Sun, 23 May 2004 04:06, Cole wrote:
: > I just wanted to know what programs any of you have used to track down a
:
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On Sun, 23 May 2004 04:06, Cole wrote:
> I just wanted to know what programs any of you have used to track down a
> memory leak in your programs?
> Also wondering if there is maybe a good tutorial on the subject under
> FreeBSD or e
In message: <[EMAIL PROTECTED]>
Tim Kientzle <[EMAIL PROTECTED]> writes:
: Cole wrote:
: > Hey
: >
: > I just wanted to know what programs any of you have used to track down a
: > memory leak in your programs?
: > Also wondering if there is maybe a good tu
On Sat, May 22, 2004 at 11:52:19AM -0700 I heard the voice of
Tim Kientzle, and lo! it spake thus:
>
> The one problem I've had is that dmalloc.h redefines some standard
> functions, which can cause gcc to complain.
I usually just have a flag in my Makefile to enable dmalloc (adding a
-D to the c
> I just wanted to know what programs any of you have used to track down a
> memory leak in your programs?
this reminds me of something... :-/
I created a port for Doug Rabson's FreeBSD port[1] of valgrind [2]. He
considered my work ready for the ports tree, but he also said that that
Cole wrote:
Hey
I just wanted to know what programs any of you have used to track down a
memory leak in your programs?
Also wondering if there is maybe a good tutorial on the subject under
FreeBSD or even linux if possible.
Im running FreeBSD 4.9 so just looking for something try to help me track
Hey
I just wanted to know what programs any of you have used to track down a
memory leak in your programs?
Also wondering if there is maybe a good tutorial on the subject under
FreeBSD or even linux if possible.
Im running FreeBSD 4.9 so just looking for something try to help me track it
down
igfree() and a related patch was applied on
> -current around August, so I did the same thing (adding an else clause
> to call contigfree(vaddr, dmat->maxsize, M_DEVBUF)).
>
> It didn't solve the memory leak problem either, so I'm stuck here...
>
> Could anyone shed a l
->maxsize <= PAGE_SIZE) && dmat->lowaddr >= ptoa(Maxmem))
free(vaddr, M_DEVBUF);
}
However, there *is* contigfree() and a related patch was applied on
-current around August, so I did the same thing (adding an else clause
to call contigfree(vaddr, dmat->maxsize,
tch/ftp.c:_ftp_close() shows a missing free(cookie) at the end of the
function.
the following patch seems to cure the memory leak :
-
--- ftp.c.ori Sat Apr 7 19:30:48 2001
+++ ftp.c Mon May 21 15:26:42 2001
@@ -422,7 +422,9 @@
io->err = 0;
close
Were there any issues related to a memory leak in the routing table ?
I am running freebsd-stable.
After a few days vmstat -m shows the memory used by routing table to be
very high and log messages "arpresolve: cant allocate llinfo for
a.b.c.d"
"arplookup a.b.c.d failed could not
Were there any issues related to a memory leak in the routing table ?
I am running freebsd-stable.
After a few days vmstat -m shows the memory used by routing table to be
very high and log messages "arpresolve: cant allocate llinfo for
a.b.c.d"
"arplookup a.b.c.d failed could not
48 matches
Mail list logo
