From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 8244 invoked by alias); 27 May 2010 19:00:40 -0000 Received: (qmail 8227 invoked by uid 22791); 27 May 2010 19:00:40 -0000 X-SWARE-Spam-Status: No, hits=-2.1 required=5.0 tests=AWL,BAYES_00,T_RP_MATCHES_RCVD X-Spam-Check-By: sourceware.org Received: from mail.codesourcery.com (HELO mail.codesourcery.com) (38.113.113.100) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Thu, 27 May 2010 19:00:35 +0000 Received: (qmail 28078 invoked from network); 27 May 2010 19:00:33 -0000 Received: from unknown (HELO orlando.localnet) (pedro@127.0.0.2) by mail.codesourcery.com with ESMTPA; 27 May 2010 19:00:33 -0000 From: Pedro Alves To: gdb-patches@sourceware.org Subject: Re: [patch] Fix crash on /proc/PID/stat race Date: Thu, 27 May 2010 19:06:00 -0000 User-Agent: KMail/1.12.2 (Linux/2.6.31-21-generic; KDE/4.3.2; x86_64; ; ) Cc: Jan Kratochvil References: <20100527175404.GA16087@host0.dyn.jankratochvil.net> In-Reply-To: <20100527175404.GA16087@host0.dyn.jankratochvil.net> MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <201005272000.26518.pedro@codesourcery.com> X-IsSubscribed: yes Mailing-List: contact gdb-patches-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-patches-owner@sourceware.org X-SW-Source: 2010-05/txt/msg00648.txt.bz2 On Thursday 27 May 2010 18:54:04, Jan Kratochvil wrote: > Hi, > > got a reported a core file that gdb crashes in linux_nat_core_of_thread_1 > called from linux_nat_wait_1 on TARGET_WAITKIND_EXITED. It crashes because > CONTENT is empty there. > > While it is understanable /proc/PID/stat is not available after > TARGET_WAITKIND_EXITED I failed to artificially reproduce it by > sleep 1&p=$!;(sleep 2;cat) as it prints > cat: -: No such process > due to > read(0, 0x65d000, 32768) = -1 ESRCH (No such process) Why are we trying to get at the core if we know the process is gone? Since the process is already waited for, I'm surprised the fopen succeeded in the first place. On a couple of quick tests, I always see fopen failing. It sounds like a kernel bug. Can't we just skip the core_of_thread call for TARGET_WAITKING_EXITED|TARGET_WAITKING_SIGNALLED? -- Pedro Alves