From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 22886 invoked by alias); 22 Mar 2004 17:33:58 -0000 Mailing-List: contact gdb-help@sources.redhat.com; run by ezmlm Precedence: bulk List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-owner@sources.redhat.com Received: (qmail 22818 invoked from network); 22 Mar 2004 17:33:55 -0000 Received: from unknown (HELO demos.bsdclusters.com) (69.55.225.36) by sources.redhat.com with SMTP; 22 Mar 2004 17:33:55 -0000 Received: from demos.bsdclusters.com (demos [69.55.225.36]) by demos.bsdclusters.com (8.12.8p1/8.12.8) with ESMTP id i2MHXkqc093114; Mon, 22 Mar 2004 09:33:46 -0800 (PST) (envelope-from kmacy@fsmware.com) Received: from localhost (kmacy@localhost) by demos.bsdclusters.com (8.12.8p1/8.12.8/Submit) with ESMTP id i2MHXkGf093110; Mon, 22 Mar 2004 09:33:46 -0800 (PST) X-Authentication-Warning: demos.bsdclusters.com: kmacy owned process doing -bs Date: Mon, 22 Mar 2004 18:17:00 -0000 From: Kip Macy X-X-Sender: kmacy@demos.bsdclusters.com To: David Carlton cc: gdb Subject: Re: generating a core file In-Reply-To: Message-ID: <20040322092717.W79960@demos.bsdclusters.com> References: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-SW-Source: 2004-03/txt/msg00201.txt.bz2 On solaris and BSD there is gcore. I assume such a thing can be found for linux and that it can be modified to write the output to a socket instead of a file. I wrote a checkpoint/restore facility for a BSD a few months back, the checkpointing part was just an extension to core dump with some extra interfaces exported. If gcore won't do the trick you could add a system call that would take a file descriptor and then pass that to the core dump routine. -Kip On Mon, 22 Mar 2004, David Carlton wrote: > This is quite off-topic, but are there any programs out there that can > generate a core file from a stopped process, and write that core file > to a pipe or send it over the network somehow? We're having issues > debugging seg faults on machines without local disks, and for various > reasons we'd rather not remotely mount disks on these machines, > either. > > David Carlton > carlton@kealia.com >