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 (vg_replace
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
Steinar H. Gunderson wrote:
I've looked through the loss records while waiting for the Omega reports:
==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 (xcommon.
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 any
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 any
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 ve
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
run
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:
http://www.brainmurders.demon.co.u
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
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 repor
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
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 se
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 = 5220
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:
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 (debian/pa
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
-329,6 +329,7 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 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 (don'
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.
>
> Thi
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 bu
19 matches
Mail list logo
