From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1756818AbYE2Upb (ORCPT ); Thu, 29 May 2008 16:45:31 -0400 Received: (majordomo@vger.kernel.org) by vger.kernel.org id S1753375AbYE2UpW (ORCPT ); Thu, 29 May 2008 16:45:22 -0400 Received: from py-out-1112.google.com ([64.233.166.178]:16116 "EHLO py-out-1112.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751065AbYE2UpV (ORCPT ); Thu, 29 May 2008 16:45:21 -0400 DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:to:subject:mime-version:content-type:content-transfer-encoding:content-disposition; b=McGW+gdZ52FGhexQ+L75ersZxXUWG/am3De2IEKuNFcQvFDZVIY94sm7wjT0WqMWotY37UZCz6Kwi0As7KMX8g/DeG0aq1xh4qnE/iB98JmxIt4u2f4A/+GZD/X9h5o7w/wLJ01UovGRAuidEixq36gT6iB+upON9GqpSuqYtMM= Message-ID: <9d95d80e0805291345t6123fe83sde5f1e1a85f9ec43@mail.gmail.com> Date: Thu, 29 May 2008 16:45:20 -0400 From: "Carlo Nyto" To: linux-kernel@vger.kernel.org Subject: Did the kernel cause this weird bash coredump? MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org I got a weird coredump from bash on a system running 2.6.25.3. Stack trace is below. Someone was tail -f'ing a log file that was being written to at a very high rate, and hit ctrl-c many times until the flood stopped (not tens of thousands of times however). This resulted in their login bash shell coredumping, when the stack filled up due to some kind of signal (or handler) misbehavior. Obviously this could be a bug in bash. But out of hundreds of identical 64-bit CentOS 4.4 systems running Redhat's 2.6.9-67 kernel, none have ever exhibited this behavior. Is it plausible that this could be caused by a kernel bug, or a change in signal behavior that could be surprising to bash or other applications? # rpm -q bash bash-3.0-19.3.x86_64 # uname -r 2.6.25.3 Core was generated by `-bash'. Program terminated with signal 11, Segmentation fault. [...] #0 0x0000003fd4a76200 in mbrtowc () from /lib64/tls/libc.so.6 (gdb) bt #0 0x0000003fd4a76200 in mbrtowc () from /lib64/tls/libc.so.6 #1 0x0000000000473888 in rl_redisplay () #2 0x0000000000471968 in rl_clear_message () #3 0x0000000000474505 in rl_free_line_state () #4 0x00000000004745c1 in rl_free_line_state () #5 #6 0x0000003fd4a2e743 in sigprocmask () from /lib64/tls/libc.so.6 #7 0x0000000000474582 in rl_free_line_state () #8 #9 0x0000003fd4a2e743 in sigprocmask () from /lib64/tls/libc.so.6 #10 0x0000000000474582 in rl_free_line_state () #11 #12 0x0000003fd4a2e743 in sigprocmask () from /lib64/tls/libc.so.6 #13 0x0000000000474582 in rl_free_line_state () [...repeat many times...] #33417 0x0000003fd4a2e743 in sigprocmask () from /lib64/tls/libc.so.6 #33418 0x0000000000474582 in rl_free_line_state () #33419 #33420 0x0000003fd4a2e743 in sigprocmask () from /lib64/tls/libc.so.6 #33421 0x0000000000474582 in rl_free_line_state () #33422 #33423 0x0000003fd4a2e5ed in sigaction () from /lib64/tls/libc.so.6 #33424 0x000000000047417d in _rl_current_display_line () #33425 0x000000000047421c in _rl_current_display_line () #33426 0x00000000004742dc in rl_set_signals () #33427 0x0000000000466e75 in readline () #33428 0x000000000041a3ea in yy_input_name () #33429 0x000000000041c1c5 in execute_prompt_command () #33430 0x000000000041d291 in execute_prompt_command () #33431 0x000000000041fd0d in yyparse () #33432 0x0000000000419e42 in parse_command () #33433 0x0000000000419ee8 in read_command () #33434 0x000000000041a05d in reader_loop () #33435 0x00000000004192a0 in main () Also seen in syslog: kernel: bash[9443]: segfault at 7ffff65ddff8 ip 3fd4a76200 sp 7ffff65ddfe0 error 6 in libc-2.3.4.so[3fd4a00000+12b000] kernel: bash used greatest stack depth: 3096 bytes left