Chris Gray <[EMAIL PROTECTED]> wrote:
>>>>>> Gary Hennigan writes:
>
> gh> "Ed Cogburn" <[EMAIL PROTECTED]> writes:
> >>>
> >>>
> >>> This is what I get with an strace on ps:
> >>>
> >>> ****************************************************************
> gh> [snip]
> >>> open("/boot/System.map", O_RDONLY|O_NONBLOCK|O_NOCTTY) = 6
> >>> fstat(6, {st_mode=S_IFREG|0664, st_size=141296, ...}) = 0
> >>> old_mmap(NULL, 141297, PROT_READ|PROT_WRITE, MAP_PRIVATE, 6, 0) =
> >>> 0x401df000
> >>> close(6) = 0
> >>> mremap(0x401be000, 135168, 12288, MREMAP_MAYMOVE) = 0x401be000
>
>It's strange that they are mremap()'ing a part of memory that didn't
>get returned by mmap(). You should send a bug report and see if they
>have heard of this.
When I looked at it earlier, I was a bit confused by not being able to
find an mremap() anywhere in the source. Now I've a bit more time, it
looks like the realloc() in procps-2.0.6/proc/ksym.c:353 is probably the
culprit; it's often implemented using mremap(). realloc() bugs are
usually caused somewhere else, as I said earlier.
In 'man malloc' there's a description of how to use the MALLOC_CHECK_
environment variable; I'd like to see the results of using that (set to
1 or 2, with or without strace, whatever's most informative).
Cheers,
--
Colin Watson [EMAIL PROTECTED]
