From: Elena Zannoni <ezannoni@redhat.com>
To: Jim Blandy <jimb@redhat.com>
Cc: gdb-patches@sources.redhat.com
Subject: Re: RFC: find core dumps on Linux
Date: Mon, 23 Jun 2003 21:08:00 -0000 [thread overview]
Message-ID: <16119.27877.29199.109565@localhost.redhat.com> (raw)
In-Reply-To: <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
> }
>
> #
next prev parent reply other threads:[~2003-06-23 21:08 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
2003-05-22 22:30 Jim Blandy
2003-05-22 22:49 ` Daniel Jacobowitz
2003-05-29 23:02 ` Jim Blandy
2003-06-23 21:08 ` Elena Zannoni [this message]
2003-06-24 3:03 Michael Elizabeth Chastain
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=16119.27877.29199.109565@localhost.redhat.com \
--to=ezannoni@redhat.com \
--cc=gdb-patches@sources.redhat.com \
--cc=jimb@redhat.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox