From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 7987 invoked by alias); 18 May 2009 13:29:43 -0000 Received: (qmail 7979 invoked by uid 22791); 18 May 2009 13:29:42 -0000 X-SWARE-Spam-Status: No, hits=-0.6 required=5.0 tests=AWL,BAYES_00,SPF_SOFTFAIL X-Spam-Check-By: sourceware.org Received: from smtp02.lnh.mail.rcn.net (HELO smtp02.lnh.mail.rcn.net) (207.172.157.102) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Mon, 18 May 2009 13:29:36 +0000 Received: from mr08.lnh.mail.rcn.net ([207.172.157.28]) by smtp02.lnh.mail.rcn.net with ESMTP; 18 May 2009 09:29:35 -0400 Received: from smtp01.lnh.mail.rcn.net (smtp01.lnh.mail.rcn.net [207.172.4.11]) by mr08.lnh.mail.rcn.net (MOS 3.10.5-GA) with ESMTP id KWF35605; Mon, 18 May 2009 09:29:34 -0400 (EDT) Received: from 65-78-31-9.c3-0.lex-ubr3.sbo-lex.ma.cable.rcn.com (HELO homebase.localnet) ([65.78.31.9]) by smtp01.lnh.mail.rcn.net with ESMTP; 18 May 2009 09:29:34 -0400 Received: from psmith by homebase.localnet with local (Exim 4.69) (envelope-from ) id 1M62uL-00010E-PQ; Mon, 18 May 2009 09:29:33 -0400 Subject: Re: Partial cores using Linux "pipe" core_pattern From: Paul Smith Reply-To: psmith@gnu.org To: Andi Kleen Cc: gdb@sourceware.org In-Reply-To: <87ab5aq3dq.fsf@basil.nowhere.org> References: <1242609756.2800.135.camel@homebase.localnet> <87ab5aq3dq.fsf@basil.nowhere.org> Content-Type: text/plain Content-Transfer-Encoding: 7bit Date: Mon, 18 May 2009 13:29:00 -0000 Message-Id: <1242653371.2800.163.camel@homebase.localnet> Mime-Version: 1.0 X-IsSubscribed: yes Mailing-List: contact gdb-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-owner@sourceware.org X-SW-Source: 2009-05/txt/msg00116.txt.bz2 On Mon, 2009-05-18 at 09:25 +0200, Andi Kleen wrote: > Paul Smith writes: > > > > Does anyone have any thoughts about where I can look next to try to > > figure out what's going on? Ideas or knowledge about limitations of the > > kernel's core_pattern pipe capability, such as timing issues etc., that > > might be leaving me with short cores? > > Sounds more like a kernel problem to me. It would be good if you > could find out in what way the cores are truncated, then do a proper > kernel bug report. > > Or add printks to the kernel coredumper and try to figure out this > way where/why it stops. Heh, I was afraid you'd say that :-). OK, I'll dig into the kernel coredumper and add some printks etc. I do have problems getting a readily reproducible test case. It seems timing related; I tried replacing my gzopen()/etc. calls with uncompressed open()/etc. and that seemed to help; no more short cores. And yet at other times I can dump the core through gzopen() no problem. -- ------------------------------------------------------------------------------- Paul D. Smith Find some GNU make tips at: http://www.gnu.org http://make.mad-scientist.us "Please remain calm...I may be mad, but I am a professional." --Mad Scientist