[SWLUG] how hard can it be... to get a core dump

[Mark Summerfield]

On 2008-09-25, Justin Mitchell wrote:
> On Thu, 2008-09-25 at 12:28 +0100, Mark Summerfield wrote:
> > On 2008-09-25, Dave Cridland wrote:
> > > On Thu Sep 25 08:16:19 2008, Mark Summerfield wrote:
> > > > and even if I use sysctl with -e I still end up with
> > > >
> > > >     $ cat /proc/sys/fs/suid_dumpable
> > > >
> > > > printing 0.
> > >
> > > Ah... If it's a setuid program, we found it easiest to do it within
> > > the source:
> >
> > It isn't a setuid program so there's no setuid() call... I just found a
> > list of instructions for making core dumps happen and followed them, and
> > the last one was to execute syctl, but I've no idea why or what it was
> > supposed to do.
>
> well typical behaviour is just the 'ulimit -c unlimited'
> which reverses any previous limit the distro set on core dumps
> that should just let the program dump core in the directory it was
> running in.
>
> the other stuff looked to be restraining where core dumps would be put,
> and allowing for otherwise not allowed core dumps for setuid programs.
>
>
> the other way of course is to not core dump at all, but run the program
> from within gdb, so it drops straight to the debugger when it crashes.
>
> 'gdb ./myprogram'
> then 'run' followed by any command line args your program needs

I tried that.

But programA runs programB and the crash only occurs in programB when it
is run from programA (with a particular data set); it runs fine on its
own or with other data. Inside gdb the crash occurs and a return value
of 01 is noted; but the backtrace gives me nothing, presumably because
gdb is debugging programA rather than the programB that crashed "inside"
it.

I think the Ubuntu people have changed the kernel to control core dumps
and this is something I can't seem to get around.

-- 
Mark Summerfield, Qtrac Ltd, www.qtrac.eu
    C++, Python, Qt, PyQt - training and consultancy
        "Programming in Python 3" - ISBN 0137129297