Re: Signal 11 when using 'ps'

[cjw44@flatline.org.uk (Colin Watson)]

Chris Gray <cgray@tribsoft.com> wrote:
>>>>>> Gary Hennigan writes:
>
>    gh> "Ed Cogburn" <ecogburn@greene.xtn.net> 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                                     [cjw44@flatline.org.uk]