public inbox for gdb-cvs@sourceware.org help / color / mirror / Atom feed
From: Tom de Vries <vries@sourceware.org> To: gdb-cvs@sourceware.org Subject: [binutils-gdb] [gdb/testsuite] Don't generate core in gdb.base/bt-on-fatal-signal.exp Date: Sat, 26 Nov 2022 13:29:38 +0000 (GMT) [thread overview] Message-ID: <20221126132938.CBB713858296@sourceware.org> (raw) https://sourceware.org/git/gitweb.cgi?p=binutils-gdb.git;h=7a0daa48da726f9c05a752e85fefe128bf848916 commit 7a0daa48da726f9c05a752e85fefe128bf848916 Author: Tom de Vries <tdevries@suse.de> Date: Sat Nov 26 14:29:10 2022 +0100 [gdb/testsuite] Don't generate core in gdb.base/bt-on-fatal-signal.exp When running test-case gdb.base/bt-on-fatal-signal.exp on powerpc64le-linux I noticed: ... FAIL: gdb.base/bt-on-fatal-signal.exp: SEGV: scan for backtrace (timeout) ... The timeout is 10 seconds, but generating the core file takes more than a minute, probably due to slow NFS. I managed to reproduce this behaviour independently of gdb, by compiling "int main (void) { __builtin_abort (); }" and running it, which took 1.5 seconds for a core file 50 times smaller than the one for gdb. Fix this by preventing the core file from being generated, using a wrapper around gdb that does "ulimit -c 0". Tested on x86_64-linux. Diff: --- gdb/testsuite/gdb.base/bt-on-fatal-signal.exp | 5 ++++- gdb/testsuite/lib/gdb.exp | 11 +++++++++++ 2 files changed, 15 insertions(+), 1 deletion(-) diff --git a/gdb/testsuite/gdb.base/bt-on-fatal-signal.exp b/gdb/testsuite/gdb.base/bt-on-fatal-signal.exp index 8f9d857106d..1af88d50c4c 100644 --- a/gdb/testsuite/gdb.base/bt-on-fatal-signal.exp +++ b/gdb/testsuite/gdb.base/bt-on-fatal-signal.exp @@ -62,7 +62,10 @@ foreach test_data {{SEGV "Segmentation fault"} \ with_test_prefix ${sig} { # Restart GDB. - clean_restart $binfile + save_vars { GDB } { + set GDB [gdb_no_core] + clean_restart $binfile + } # Capture the pid of GDB. set testpid [spawn_id_get_pid $gdb_spawn_id] diff --git a/gdb/testsuite/lib/gdb.exp b/gdb/testsuite/lib/gdb.exp index 7d05fbe557b..a73437a419f 100644 --- a/gdb/testsuite/lib/gdb.exp +++ b/gdb/testsuite/lib/gdb.exp @@ -6322,6 +6322,17 @@ proc cached_file { filename txt {executable 0}} { return $filename } +# Return a wrapper around gdb that prevents generating a core file. + +proc gdb_no_core { } { + set script \ + [list \ + "ulimit -c 0" \ + [join [list exec $::GDB {"$@"}]]] + set script [join $script "\n"] + return [cached_file gdb-no-core.sh $script 1] +} + # Set 'testfile', 'srcfile', and 'binfile'. # # ARGS is a list of source file specifications.
reply other threads:[~2022-11-26 13:29 UTC|newest] Thread overview: [no followups] expand[flat|nested] mbox.gz Atom feed
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=20221126132938.CBB713858296@sourceware.org \ --to=vries@sourceware.org \ --cc=gdb-cvs@sourceware.org \ /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: linkBe 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; as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).