AF:
NF:0
PS:10
SRH:1
SFN:
DSR:
MID:<20090330172800.41205d50@ripper.onstor.net>
CFG:
PT:0
S:andy.sharp@onstor.com
RQ:
SSV:mail.onstor.net
NSV:
SSH:
R:<rendell.fong@onstor.com>
MAID:1
X-Sylpheed-Privacy-System:
X-Sylpheed-Sign:0
SCF:#mh/Mailbox/sent
RMID:#imap/andys@onstor.net@exch1.onstor.net/INBOX	0	2779531E7C760D4491C96305019FEEB52AC8BC1D36@exch1.onstor.net
X-Sylpheed-End-Special-Headers: 1
Date: Mon, 30 Mar 2009 17:28:07 -0700
From: Andrew Sharp <andy.sharp@onstor.com>
To: Rendell Fong <rendell.fong@onstor.com>
Subject: Re: Tuxrx core dump
Message-ID: <20090330172807.7c6971c3@ripper.onstor.net>
In-Reply-To: <2779531E7C760D4491C96305019FEEB52AC8BC1D36@exch1.onstor.net>
References: <20090325105603.1b01c366@ripper.onstor.net>
	<2779531E7C760D4491C96305019FEEB52AC8BC1D36@exch1.onstor.net>
Organization: Onstor
X-Mailer: Sylpheed-Claws 2.6.0 (GTK+ 2.8.20; x86_64-pc-linux-gnu)
Mime-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit

Individual programs can change this for themselves, yes?  I believe
that's how we get core dumps for all the onstor daemons if they have a
segfault.

On Mon, 30 Mar 2009 17:23:43 -0700 Rendell Fong
<rendell.fong@onstor.com> wrote:

> I have found that the core dump can be enabled by simply adding "ulimit -c unlimited" command to /etc/profile.  The core dump file will end up in /var/run directory.
> 
> Core dump is normally disabled since "ulimit -c" is set to zero by default.
> I haven't been able to figure out how to change the default.  So hopefully changing the profile is adequate.
> 
> 
> > -----Original Message-----
> > From: Andy Sharp 
> > Sent: Wednesday, March 25, 2009 10:56 AM
> > To: Rendell Fong
> > Subject: Re: Tuxrx core dump
> > 
> > On Wed, 25 Mar 2009 10:24:15 -0700 Rendell Fong 
> > <rendell.fong@onstor.com> wrote:
> > 
> > > Andy,
> > > 
> > > I've located the core dump code.  Can you provide me with 
> > some steps 
> > > for building the kernel? I assume we need core dumps configured for 
> > > ELF format.  So I want to verify whether things are configured as 
> > > expected.
> > 
> > Whatever format gdb wants, which is ELF of course.  But it's 
> > already configured for that.
> > 
> > > Then, I need to run it and get acquainted with the current behavior.
> > > I haven't tried crashing kernel threads before.  So I don't 
> > know how 
> > > they are handled differently from the ones running in user mode.
> > 
> > User mode threads don't end up in oops or panic ~:^)
> > 
> > > (1) I'll have to add some code to generate a crash file update 
> > > (normally stored in /var/crash assuming the existing functionality 
> > > doesn't change).  It just has an entry per crash with a 
> > backtrace and 
> > > dump of register contents.
> > 
> > Just add some code, a one liner or something, that would 
> > generate a segfault or bus error.  A null dereference should 
> > do the trick.
> > 
> > > (2) The default core file naming convention is 
> > "core.<pid>", but can 
> > > be changed to include more thread specific info. Need to determine 
> > > what info is needed and how to get it.
> > 
> > I believe we already change that.
> > 
> > > That's all I can think of at the moment.
> > > 
> > > Rendell
> > > 
> > 