Re: Signal 11 when using 'ps'
>>>>> 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.
>>> --- SIGSEGV (Segmentation fault) ---
>>> write(2, "\n\nSignal 11 caught by ps (procps"..., 98
>>>
>>> Signal 11 caught by ps (procps version 2.0.6).
>>> Please send bug reports to <acahalan@cs.uml.edu>
>>> ) = 98
>>> _exit(139) = ?
>>> ****************************************************************
>>> Now I'm getting a consistent and repeatable sig11 from
>>> console-apt/dpkg. I thought sig11 is a memory problem, but
>>> the memtester in my BIOS, and memtest-86 v2.4 (3 passes) both
>>> show no errors in my RAM. Yet the mremap function above is a
>>> memory-related function, so I'm stumped. When I originally
>>> moved to this new machine, I wasn't getting sig11 errors, but
>>> there have been hardware (not memory) and software (massive
>>> Debian upgrade) changes since then, and I can't remember
>>> exactly when this started. Can sig11 mean something other
>>> than a memory problem?
gh> Yeah, it can be caused by quite a variety of hardware
gh> problems, it's just the memory is the most probable. Take a
gh> look at the SIG11 FAQ here:
Signal 11 is also caused by programming errors. For example, the capt
segfault is just a bug. In this case, however, it looks like it could
be a hardware problem. Ed, is your CPU overclocked?
--
Chris (who's caused way too many signal 11's with "interesting" programming)
Reply to: