|
From: Eyal L. <ey...@ey...> - 2004-01-14 08:24:18
Attachments:
xxx
|
Testing a busy server, with many threads, I ended up with this a long report (attached) that starts with: valgrind: vg_malloc2.c:1008 (vgPlain_arena_malloc): Assertion `new_sb != ((void *)0)' failed. It seem to only happen when I use UDB database. This off current cvs. -- Eyal Lebedinsky (ey...@ey...) <http://samba.org/eyal/> |
|
From: Robert W. <rj...@du...> - 2004-01-14 08:34:59
|
On Wed, 2004-01-14 at 00:23, Eyal Lebedinsky wrote: > Testing a busy server, with many threads, I ended up with > this a long report (attached) that starts with: >=20 > valgrind: vg_malloc2.c:1008 (vgPlain_arena_malloc): Assertion `new_sb != =3D > ((void *)0)' failed. >=20 > It seem to only happen when I use UDB database. >=20 > This off current cvs. Is it possible you're running out of memory or address space? Remember, Valgrind takes up wads more memory than running the problem without Valgrind... Regards, Robert. --=20 Robert Walsh Amalgamated Durables, Inc. - "We don't make the things you buy." Email: rj...@du... |
|
From: Eyal L. <ey...@ey...> - 2004-01-15 08:49:45
|
Robert Walsh wrote: > > On Wed, 2004-01-14 at 00:23, Eyal Lebedinsky wrote: > > Testing a busy server, with many threads, I ended up with > > this a long report (attached) that starts with: > > > > valgrind: vg_malloc2.c:1008 (vgPlain_arena_malloc): Assertion `new_sb != > > ((void *)0)' failed. > > > > It seem to only happen when I use UDB database. > > > > This off current cvs. > > Is it possible you're running out of memory or address space? Remember, > Valgrind takes up wads more memory than running the problem without > Valgrind... OK, I had a close look and I do not think a memory shortage is involved. At the point of failure a malloc(exactly 64MB) was done. It never returned. However, the same sort of malloc() followed by a free() was done a number of times earlier. If vg holds on to freed memory then there may be a problem. The machine is 1GB memory and 2GB swap and abour 450MB of swap was used at the time of failure. I am running with: --tool=memcheck --leak-check=yes --show-reachable=no --num-callers=32 --error-limit=no --run-libc-freeres=no --quiet --trace-children=no -- Eyal Lebedinsky (ey...@ey...) <http://samba.org/eyal/> |
|
From: Robert W. <rj...@du...> - 2004-01-15 08:57:15
|
> However, the same sort of malloc() followed by a free() was > done a number of times earlier. If vg holds on to freed > memory then there may be a problem. The machine is 1GB memory > and 2GB swap and abour 450MB of swap was used at the time > of failure. Valgrind does hold on to memory for a certain length of time after it's been freed. This is to catch things like this: x =3D malloc(10); free(x); y =3D malloc(10); *x =3D 0; If the second malloc happed to return the same value as the first, the invalid write to *x would never be caught. However, it doesn't keep these forever, and I had assumed it would use that pool when it ran out of memory. Hmm. Too tired to look at the code now, but it's in there somewhere. Search for freed_list. Regards, Robert. --=20 Robert Walsh Amalgamated Durables, Inc. - "We don't make the things you buy." Email: rj...@du... |
|
From: Julian S. <js...@ac...> - 2004-01-15 18:40:33
|
On Thursday 15 January 2004 08:57, Robert Walsh wrote:
> > However, the same sort of malloc() followed by a free() was
> > done a number of times earlier. If vg holds on to freed
> > memory then there may be a problem. The machine is 1GB memory
> > and 2GB swap and abour 450MB of swap was used at the time
> > of failure.
>
> Valgrind does hold on to memory for a certain length of time after it's
> been freed. This is to catch things like this:
>
> x = malloc(10);
> free(x);
> y = malloc(10);
> *x = 0;
>
> If the second malloc happed to return the same value as the first, the
> invalid write to *x would never be caught.
>
> However, it doesn't keep these forever, and I had assumed it would use
> that pool when it ran out of memory. Hmm. Too tired to look at the
> code now, but it's in there somewhere. Search for freed_list.
Command-line parameter:
--freelist-vol=<number> volume of freed blocks queue [1000000]
Eyal, try with ...=0
J
|
|
From: Eyal L. <ey...@ey...> - 2004-01-16 07:51:27
|
Julian Seward wrote: > > On Thursday 15 January 2004 08:57, Robert Walsh wrote: > > > However, the same sort of malloc() followed by a free() was > > > done a number of times earlier. If vg holds on to freed > > > memory then there may be a problem. The machine is 1GB memory > > > and 2GB swap and abour 450MB of swap was used at the time > > > of failure. > > > > Valgrind does hold on to memory for a certain length of time after it's > > been freed. This is to catch things like this: > > > > x = malloc(10); > > free(x); > > y = malloc(10); > > *x = 0; > > > > If the second malloc happed to return the same value as the first, the > > invalid write to *x would never be caught. > > > > However, it doesn't keep these forever, and I had assumed it would use > > that pool when it ran out of memory. Hmm. Too tired to look at the > > code now, but it's in there somewhere. Search for freed_list. > > Command-line parameter: > --freelist-vol=<number> volume of freed blocks queue [1000000] Used '--freelist-vol=0' - no change. Furthermore, since I know the failure is in a malloc that never returns, I put a sleep(2) just before the malloc and started a 'vmstat 1'. It fails in the same way and only under 400MB of swap (out of 2GB) is used max. Is there any other tracing I can turn on to help diagnose the problem? -- Eyal Lebedinsky (ey...@ey...) <http://samba.org/eyal/> |