Empty core dump file

Empty core dump file

[David Aldrich]

Hi

I am new to examining core dump files using gdb.  I am running Centos 5.5.

When my C++ program crashes with a segmentation fault I get an empty core dump file called core.13754.

I have previously executed:

ulimit -c unlimited

I built with -g.

Why might the core dump be empty?

Why does the filename include a number?

(/proc/sys/kernel/core_pattern contains just 'core').

Best regards

David

Re: Empty core dump file

[Baurzhan Ismagulov]

On Fri, Aug 26, 2011 at 12:35:59PM +0000, David Aldrich wrote:
> When my C++ program crashes with a segmentation fault I get an empty
> core dump file called core.13754.
...
> ulimit -c unlimited

I wouldn't expect any problems if you don't get an error message after
this command, but I'd double-check ulimit -Sc and ulimit -Hc outputs.


> Why might the core dump be empty?

You do have space on the device, don't you?


> Why does the filename include a number?

See /proc/sys/kernel/core_uses_pid.


Is this i386?


With kind regards,
Baurzhan.

RE: Empty core dump file

[David Aldrich]

> On Fri, Aug 26, 2011 at 12:35:59PM +0000, David Aldrich wrote:
> > When my C++ program crashes with a segmentation fault I get an empty
> > core dump file called core.13754.
> ...
> > ulimit -c unlimited
> 
> I wouldn't expect any problems if you don't get an error message after this
> command, but I'd double-check ulimit -Sc and ulimit -Hc outputs.

$ ulimit -Sc
unlimited
$ ulimit -Hc
unlimited

> > Why might the core dump be empty?
> 
> You do have space on the device, don't you?

Yes, but I have just realised that I am working on a shared drive from a VM. There may be some permissions problem. I will check.

> Is this i386?

It's a 64-bit Linux VM.

Thanks for your help.

David

RE: Empty core dump file

[David Aldrich]

Hi 

I would like to revisit this problem please.

To recap, I am debugging a program hosted by a Centos 5.5 virtual machine (using VirtualBox).  When the program is built on a shared (with Windows) folder  I find that any resulting core file is of zero length.

I have run: ulimit -c unlimited

This is a file permissions problem because if I mount the shared folder with a specific uid the core file is correctly saved.  So I must use a mount command such as:

mount -t vboxsf -o rw,uid=1000,gid=1000 SVNProj /media/SVNProj

which I store in /etc/rc.local

If I omit uid the core file becomes empty.

The problem with this is that I must customise the mount command for each user, i.e. mount needs their uid.

Is there a better solution for this problem please?

Best regards

David

RE: Empty core dump file

[Worley, Dale R (Dale)]

> From: David Aldrich [David.Aldrich@EMEA.NEC.COM]
> 
> This is a file permissions problem because if I mount the shared
> folder with a specific uid the core file is correctly saved.  So I
> must use a mount command such as:
> 
> mount -t vboxsf -o rw,uid=1000,gid=1000 SVNProj /media/SVNProj
> 
> which I store in /etc/rc.local
> 
> If I omit uid the core file becomes empty.
> 
> The problem with this is that I must customise the mount command for
> each user, i.e. mount needs their uid.
> 
> Is there a better solution for this problem please?

As you say, this is a file permission problem.  By default, the core
file is writtin in the current directory of the process that has
crashed; if the crashing process cannot write into its current
directory, a core file cannot be generated.

The ideal solution is to have the current directory be writable by the
process, as that is by far the commonest situation in Un*x operations,
and there are likely to be other standard system management operations
that fail if the process cannot write its current directory.

Can you arrange your processes to not change their current directory
to /media/SVNProj?  Or if you really intend every user to be able to
write into /media/SVNProj, change the permissions on that directory so
they can.

Another approach would be to have the core files written in another
directory.  I'm not sure of the details but the manual page core(5)
says that with 2.6 kernels and 2.4 kernels after 2.4.21, there is a
/proc/sys/kernel/core_pattern file that seems to allow specification
of the directory for the core file.  So you could do

    echo '/tmp/core.%p' >/proc/sys/kernel/core_pattern

and have all core files written into the /tmp directory.

Dale

Re: Empty core dump file

[Baurzhan Ismagulov]

On Fri, Sep 02, 2011 at 12:44:58PM +0000, David Aldrich wrote:
> This is a file permissions problem because if I mount the shared
> folder with a specific uid the core file is correctly saved. So I must
> use a mount command such as:
...
> which I store in /etc/rc.local
...
> The problem with this is that I must customise the mount command for
> each user, i.e. mount needs their uid.

Mounting per-user in session init file with sudo? There is a number of
other options depending on what you can / want to change, such as using
nfs with groups or granting write permissions to all users (this depends
on the entity denying the access, I'm not familiar with vboxsf).

With kind regards,
Baurzhan.

RE: Empty core dump file

[David Aldrich]

> > This is a file permissions problem because if I mount the shared
> > folder with a specific uid the core file is correctly saved.  So I
> > must use a mount command such as:
> >
> > mount -t vboxsf -o rw,uid=1000,gid=1000 SVNProj /media/SVNProj
> >
> > which I store in /etc/rc.local
> >
> > If I omit uid the core file becomes empty.
> >
> > The problem with this is that I must customise the mount command for
> > each user, i.e. mount needs their uid.
> >
> > Is there a better solution for this problem please?
> 
> As you say, this is a file permission problem.  By default, the core file is writtin
> in the current directory of the process that has crashed; if the crashing
> process cannot write into its current directory, a core file cannot be
> generated.
> 
> The ideal solution is to have the current directory be writable by the process,
> as that is by far the commonest situation in Un*x operations, and there are
> likely to be other standard system management operations that fail if the
> process cannot write its current directory.
> 
> Can you arrange your processes to not change their current directory to
> /media/SVNProj?  Or if you really intend every user to be able to write into
> /media/SVNProj, change the permissions on that directory so they can.
> 
> Another approach would be to have the core files written in another
> directory.  I'm not sure of the details but the manual page core(5) says that
> with 2.6 kernels and 2.4 kernels after 2.4.21, there is a
> /proc/sys/kernel/core_pattern file that seems to allow specification of the
> directory for the core file.  So you could do
> 
>     echo '/tmp/core.%p' >/proc/sys/kernel/core_pattern
> 
> and have all core files written into the /tmp directory.

Thanks for your suggestion of storing the core files in /tmp.  I think that will be very suitable for us.

I have set the core pattern to:

kernel.core_pattern=/tmp/corefiles/core.%e.%p.%t

On Centos 5.5, script /etc/cron.daily/tmpwatch calls tmpwatch to periodically purge /tmp.  This is good as it will delete old core files but I can't work out whether it will delete directory /tmp/corefiles.  If it does, then new core files will not be saved.  Of course, with your suggestion where the core files are just stored in /tmp that would not be a problem.

Has anyone configured a similar set up successfully?

David

Re: Empty core dump file

[Jan Kratochvil]

On Tue, 06 Sep 2011 12:43:51 +0200, David Aldrich wrote:
> I can't work out whether it will delete directory /tmp/corefiles.  If it
> does, then new core files will not be saved.

Not tested on CentOS-5.x but at least still Fedora 14 (and therefore I believe
even CentOS-5.x) tmpwatch has a bug the directories are never removed.
(I haven't investigated what is the real reason for it, whether it isn't just
due to updatedb (although it has /tmp in PRUNEPATHS) etc.)


Jan

RE: Empty core dump file

[David Aldrich]

> > I can't work out whether it will delete directory /tmp/corefiles.  If
> > it does, then new core files will not be saved.
> 
> Not tested on CentOS-5.x but at least still Fedora 14 (and therefore I believe
> even CentOS-5.x) tmpwatch has a bug the directories are never removed.
> (I haven't investigated what is the real reason for it, whether it isn't just due
> to updatedb (although it has /tmp in PRUNEPATHS) etc.)
> 

Thanks for this information.

David