This is the mail archive of the
gdb-patches@sources.redhat.com
mailing list for the GDB project.
Re: RFC: find core dumps on Linux
- From: Elena Zannoni <ezannoni at redhat dot com>
- To: Jim Blandy <jimb at redhat dot com>
- Cc: gdb-patches at sources dot redhat dot com
- Date: Mon, 23 Jun 2003 17:11:01 -0400
- Subject: Re: RFC: find core dumps on Linux
- References: <vt2u1bmr4jj.fsf@zenia.red-bean.com>
Jim Blandy writes:
>
> I didn't realize this, but for a very long time, gdb.base/coredump.exp
> has been broken on Linux. Linux creates core files named 'core.PID';
> the test suite didn't know how to find them, so it suggested you check
> your 'ulimit -c' setting and skipped the tests.
I think this is ok, and useful. Should go on the branch as well.
elena
>
> 2003-05-22 Jim Blandy <jimb@redhat.com>
>
> * gdb.base/corefile.exp: Find corefiles on Linux, which names them
> 'core.PID'.
>
> Index: gdb/testsuite/gdb.base/corefile.exp
> ===================================================================
> RCS file: /cvs/src/src/gdb/testsuite/gdb.base/corefile.exp,v
> retrieving revision 1.5
> diff -c -r1.5 corefile.exp
> *** gdb/testsuite/gdb.base/corefile.exp 17 Dec 2001 21:03:48 -0000 1.5
> --- gdb/testsuite/gdb.base/corefile.exp 22 May 2003 22:22:43 -0000
> ***************
> *** 54,69 ****
> # allows us to generate a core on systems where it does.
> #
> # Some systems append "core" to the name of the program; others append
> ! # the name of the program to "core".
> set found 0
> ! catch "system \"(cd ${objdir}/${subdir}; ulimit -c unlimited; ${binfile}; true) >/dev/null 2>&1\""
> # remote_exec host "${binfile}"
> ! foreach i "${objdir}/${subdir}/core ${objdir}/${subdir}/core.coremaker.c ${binfile}.core" {
> if [remote_file build exists $i] {
> remote_exec build "mv $i ${objdir}/${subdir}/corefile"
> set found 1
> }
> }
> if { $found == 0 } {
> # The braindamaged HPUX shell quits after the ulimit -c above
> # without executing ${binfile}. So we try again without the
> --- 54,83 ----
> # allows us to generate a core on systems where it does.
> #
> # Some systems append "core" to the name of the program; others append
> ! # the name of the program to "core"; still others (like Linux, as of
> ! # May 2003) create cores named "core.PID". In the latter case, we
> ! # could have many core files lying around, and it may be difficult to
> ! # tell which one is ours, so let's run the program in a subdirectory.
> set found 0
> ! set coredir "${objdir}/${subdir}/coredir.[getpid]"
> ! file mkdir $coredir
> ! catch "system \"(cd ${coredir}; ulimit -c unlimited; ${binfile}; true) >/dev/null 2>&1\""
> # remote_exec host "${binfile}"
> ! foreach i "${coredir}/core ${coredir}/core.coremaker.c ${binfile}.core" {
> if [remote_file build exists $i] {
> remote_exec build "mv $i ${objdir}/${subdir}/corefile"
> set found 1
> }
> }
> + # Check for "core.PID".
> + if { $found == 0 } {
> + set names [glob -nocomplain -directory $coredir core.*]
> + if {[llength $names] == 1} {
> + set corefile [file join $coredir [lindex $names 0]]
> + remote_exec build "mv $corefile ${objdir}/${subdir}/corefile"
> + set found 1
> + }
> + }
> if { $found == 0 } {
> # The braindamaged HPUX shell quits after the ulimit -c above
> # without executing ${binfile}. So we try again without the
> ***************
> *** 77,87 ****
> set found 1
> }
> }
>
> ! if { $found == 0 } {
> ! warning "can't generate a core file - core tests suppressed - check ulimit -c"
> ! return 0
> ! }
> }
>
> #
> --- 91,105 ----
> set found 1
> }
> }
> + }
> +
> + # Try to clean up after ourselves.
> + remote_file build delete [file join $coredir coremmap.data]
> + remote_exec build "rmdir $coredir"
>
> ! if { $found == 0 } {
> ! warning "can't generate a core file - core tests suppressed - check ulimit -c"
> ! return 0
> }
>
> #