Steinar H. Gunderson wrote:
thread, you'll see this patch which I wrote to fix the 1.1.0 issue. Could you
please try it under 1.0.12 and see if it fixes your problem?
I should backport the 1.0.12 from testing to etch? Is it OK if I use the
etch version instead? I'll set up a test machine
Steinar H. Gunderson wrote:
thread, you'll see this patch which I wrote to fix the 1.1.0 issue. Could you
please try it under 1.0.12 and see if it fixes your problem?
--- a/support/export/client.c
+++ b/support/export/client.c
at at -329,6 +329,7 at at add_name(char *old, char *add)
Steinar H. Gunderson wrote:
thread, you'll see this patch which I wrote to fix the 1.1.0 issue. Could you
please try it under 1.0.12 and see if it fixes your problem?
I've compiled the 1.0.12-4 package from testing on stable. Version
1.0.12-4 already contains the patch you suggested
On Thu, May 10, 2007 at 09:11:14AM +0200, Rik Theys wrote:
I should backport the 1.0.12 from testing to etch?
Sorry, I mistyped -- I meant the etch version (1.0.10), of course.
Define tons. Since the last time I restarted nfs-kernel-server
(approx. 6 days and 1 hour = 8700 minutes = 522000
On Thu, May 10, 2007 at 10:28:23AM +0200, Rik Theys wrote:
I've created a new package based on the etch package with the above file
patched, but it doesn't seem to help: the memory leak is still there.
OK, so my guess was right -- it's not that fix, it's something else.
I reproduced the
Steinar H. Gunderson wrote:
Your best guess at this point is probably Valgrind. Recompile the etch
version with debug information (remove the dh_strip line in debian/rules),
then run mountd with valgrind --leak-check=full rpc.mountd -F -d all. After
it's started leaking, just Ctrl-C it and see
On Thu, May 10, 2007 at 02:57:46PM +0200, Rik Theys wrote:
In attach the valgrind output with libc6-dbg installed and /etc/nsswitch
configured to use files for netgroups instead of ldap. The memory leaks
is still there.
This is very interesting; at least it shows that there are definitely
On Thu, May 10, 2007 at 02:57:46PM +0200, Rik Theys wrote:
In attach the valgrind output with libc6-dbg installed and /etc/nsswitch
configured to use files for netgroups instead of ldap. The memory leaks
is still there.
I've looked through the loss records while waiting for the Omega
On Thu, May 10, 2007 at 03:38:25PM +0200, Rik Theys wrote:
I've downloaded valgrind and omega as described on the above site, but
I'm getting the following error running autogen.sh:
bunnahabhain:~/omega/valgrind# ./autogen.sh
running: aclocal
running: autoheader
running: automake -a
Steinar H. Gunderson wrote:
This is very interesting; at least it shows that there are definitely leaks,
even though I can't reproduce them here.
Do you have the possibility of compiling your own Valgrind? In that case, a
run with Omega could be very useful:
Steinar H. Gunderson wrote:
On Thu, May 10, 2007 at 03:38:25PM +0200, Rik Theys wrote:
I've downloaded valgrind and omega as described on the above site, but
I'm getting the following error running autogen.sh:
bunnahabhain:~/omega/valgrind# ./autogen.sh
running: aclocal
running: autoheader
On Thu, May 10, 2007 at 03:44:58PM +0200, Rik Theys wrote:
I've tried all of these:
1/usr/bin/automake-1.10
2/usr/bin/automake-1.7
3/usr/bin/automake-1.8
*+4/usr/bin/automake-1.9
I don't think etch comes with any older/newer versions
Steinar H. Gunderson wrote:
On Thu, May 10, 2007 at 03:44:58PM +0200, Rik Theys wrote:
I've tried all of these:
1/usr/bin/automake-1.10
2/usr/bin/automake-1.7
3/usr/bin/automake-1.8
*+4/usr/bin/automake-1.9
I don't think etch comes with
Steinar H. Gunderson wrote:
On Thu, May 10, 2007 at 03:44:58PM +0200, Rik Theys wrote:
I've tried all of these:
1/usr/bin/automake-1.10
2/usr/bin/automake-1.7
3/usr/bin/automake-1.8
*+4/usr/bin/automake-1.9
I don't think etch comes with
Steinar H. Gunderson wrote:
I've looked through the loss records while waiting for the Omega reports:
snip/
==19854== 168,672 bytes in 2,745 blocks are definitely lost in loss record 19
of 20
==19854==at 0x401D38B: malloc (vg_replace_malloc.c:149)
==19854==by 0x80531D7: xmalloc
On Thu, May 10, 2007 at 04:10:34PM +0200, Rik Theys wrote:
When I unpack the 3.2.3 version I can apply the omega patch, but when I
configure, make, make install it, there's no omega support :-/
Try autoreconf -i.
/* Steinar */
--
Homepage: http://www.sesse.net/
--
To UNSUBSCRIBE, email to
Steinar H. Gunderson wrote:
I've looked through the loss records while waiting for the Omega reports:
I've got that compiled. Against which version should I run it?
==19854== 6,150 bytes in 256 blocks are definitely lost in loss record 15 of 20
==19854==at 0x401D38B: malloc
Package: nfs-kernel-server
Version: 1:1.0.10-6
Severity: important
On a busy NFS server, rpc.mountd starts to slowly eat a _lot_ of memory. I
usually restart
it when the amount of memory reaches 1.6Gb (which is approx. 10% of the system
memory).
This is after approx. 2 weeks of uptime.
This
On Wed, May 09, 2007 at 10:24:49PM +0200, Rik Theys wrote:
On a busy NFS server, rpc.mountd starts to slowly eat a _lot_ of memory. I
usually restart
it when the amount of memory reaches 1.6Gb (which is approx. 10% of the
system memory).
This is after approx. 2 weeks of uptime.
This bug
19 matches
Mail list logo
