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
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 adscomp...@gmail.com wrote:
Hi All,
Please help to solve a kernel memory leak problem.
After few
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 'top -H' I see in turn 2
or 4
MG threads. So it looks like memory leak when thread
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
simple in use. It was very useful when I
memory leak when thread is removed. Should I fill
PR?
It looks like I have found the leak. The problem is in libgomp/team.c.
gomp_thread_start() does sem_init() but sem_destroy() is never called. This
patch solves the problem for me:
--- contrib/gcclibs/libgomp/team.c.orig 2009-05-16 17:32
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?
It looks like I have found the leak. The problem is in libgomp/team.c.
gomp_thread_start() does sem_init() but sem_destroy() is never called. This
patch solves
() 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?
It looks like I have found the leak. The problem is in libgomp/team.c.
gomp_thread_start() does sem_init() but sem_destroy() is never
. 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 fill
PR?
I can confirm this. I briefly looked through
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
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
http
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
(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
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 run out of memory:
login
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
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
assigned to the new_body
buffer
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 parameter list is too long
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 gzipped binaries
^^
when
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
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
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 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 */
if (inflate_codes(glbl, tl, td
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.tar.bz2
Seán
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
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 is
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 permit programs to
continue to use
.
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 was to permit
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]
___
/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 assumed
[EMAIL PROTECTED] ~/src/gai% cat gai.c
#include sys/types.h
#include sys/socket.h
#include netdb.h
#include string.h
int
main(void)
{
struct addrinfo hint, *res;
memset(hint, 0, sizeof(hint));
hint.ai_family = AF_INET;
hint.ai_socktype = SOCK_STREAM;
On Wed, Feb 16, 2005 at 12:16:26PM +0100, Dag-Erling Smørgrav wrote:
[EMAIL PROTECTED] ~/src/gai% cat gai.c
#include sys/types.h
#include sys/socket.h
#include netdb.h
#include string.h
int
main(void)
{
struct addrinfo hint, *res;
memset(hint, 0, sizeof(hint));
Brian Feldman [EMAIL PROTECTED] writes:
URL: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
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
: memory leak in your programs?
: Also
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
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?
this reminds me of something
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
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
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
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
he doesn't
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 cc
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 tutorial on the subject under
: FreeBSD
))
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, M_DEVBUF)).
It didn't solve the memory leak problem either, so I'm stuck here
= 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, M_DEVBUF)).
It didn't solve the memory leak problem
() 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(io-csd);
io-csd = -1
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 allocate llinfo
46 matches
Mail list logo
