Re: track down why malloc fails

jklowden%schemamania.org@localhost ("James K. Lowden") writes:
>Done. I've ruled out insufficient memory as the cause, and I don't
>understand how to read the kdump output.
The trace says that there is insufficient memory.
>data(kbytes) 131072
>That tells me the process can allocate 256 MB of memory.
128MB
>The ktrace.out was 757,271,470 bytes. What's odd is that when I re-ran
>the job this morning (under my account) the ktrace.out is 10% of that
>size: 85,489,521 bytes.
Apparently it is not doing the same, which might the reason why
it uses more memory.
> 28999 svn CALL break(0x1005b000)
> 28999 svn RET break 0
This should give you a hint on how much memory has been allocated,
unfortunately this only gives the end of the data segment and
not the beginning, which depends on the platform, and there might
be other caveats.
Search for the first break() call to see roughly where it starts. Here
(i386,netbsd-4) I get when running 'svn help':
27342 1 svn CALL break(0x8062ec0)
27342 1 svn RET break 0
[...]
27342 1 svn CALL break(0x807b000)
27342 1 svn RET break 0
and the delta is about 100kB.
If your trace was created on a similar system then the process
has allocated roughly 128MB and that's why the mmap() fails.
--
--
Michael van Elst
Internet: mlelstv%serpens.de@localhost
"A potential Snark may lurk in every tree."