Valgrind reports a leak in the dwarf reader (see details below).
The function dw2_get_file_names_reader is interning in the per_objfile
all the file names it finds, except the name of 'fnd file name and directory'.
Instead, it was xstrdup-ing the name.
Fix the leaks by also interning the name.
This was validated running the tests natively, and under valgrind.
Leaks have decreased as mentionned below.
Valgrind detected no error such as double free or use after free.
Stack trace of the leak:
==4113266== 490,735 bytes in 17,500 blocks are definitely lost in loss record 7,061 of 7,074
==4113266== at 0x483979B: malloc (vg_replace_malloc.c:393)
==4113266== by 0x25A454: xmalloc (alloc.c:57)
==4113266== by 0x7D1E1E: xstrdup (xstrdup.c:34)
==4113266== by 0x39D141: dw2_get_file_names_reader (read.c:2825)
==4113266== by 0x39D141: dw2_get_file_names(dwarf2_per_cu_data*, dwarf2_per_objfile*) (read.c:2851)
==4113266== by 0x39DD6C: dw_expand_symtabs_matching_file_matcher(dwarf2_per_objfile*, gdb::function_view<bool (char const*, bool)>) (read.c:4149)
==4113266== by 0x3BC8B5: cooked_index_functions::expand_symtabs_matching(objfile*, gdb::function_view<bool (char const*, bool)>, lookup_name_info const*, gdb::function_view<bool (char const*)>, gdb::function_view<bool (compunit_symtab*)>, enum_flags<block_search_flag_values>, domain_enum, search_domain) (read.c:18688)
==4113266== by 0x5DD1EA: objfile::map_symtabs_matching_filename(char const*, char const*, gdb::function_view<bool (symtab*)>) (symfile-debug.c:207)
==4113266== by 0x5F04CC: iterate_over_symtabs(char const*, gdb::function_view<bool (symtab*)>) (symtab.c:633)
==4113266== by 0x477EE3: collect_symtabs_from_filename(char const*, program_space*) (linespec.c:3712)
==4113266== by 0x477FC1: symtabs_from_filename(char const*, program_space*) (linespec.c:3726)
==4113266== by 0x47A9B8: convert_explicit_location_spec_to_linespec(linespec_state*, linespec*, char const*, char const*, symbol_name_match_type, char const*, line_offset) (linespec.c:2329)
==4113266== by 0x47E86E: convert_explicit_location_spec_to_sals (linespec.c:2388)
==4113266== by 0x47E86E: location_spec_to_sals(linespec_parser*, location_spec const*) (linespec.c:3104)
==4113266== by 0x47EDAC: decode_line_full(location_spec*, int, program_space*, symtab*, int, linespec_result*, char const*, char const*) (linespec.c:3149)
...
Without the fix, the top 10 leaks are:
./gdb/testsuite/outputs/gdb.base/condbreak-bad/gdb.log:345:==3213924== definitely lost: 130,937 bytes in 5,409 blocks
./gdb/testsuite/outputs/gdb.base/hbreak2/gdb.log:619:==3758919== definitely lost: 173,323 bytes in 7,204 blocks
./gdb/testsuite/outputs/gdb.mi/mi-var-cp/gdb.log:1320:==4152873== definitely lost: 172,826 bytes in 7,207 blocks
./gdb/testsuite/outputs/gdb.base/advance-until-multiple-locations/gdb.log:398:==2992643== definitely lost: 172,965 bytes in 7,211 blocks
./gdb/testsuite/outputs/gdb.mi/mi-var-cmd/gdb.log:2302:==4159476== definitely lost: 173,129 bytes in 7,211 blocks
./gdb/testsuite/outputs/gdb.cp/gdb2384/gdb.log:222:==3811851== definitely lost: 218,106 bytes in 7,761 blocks
./gdb/testsuite/outputs/gdb.cp/mb-templates/gdb.log:310:==3787344== definitely lost: 290,311 bytes in 10,340 blocks
./gdb/testsuite/outputs/gdb.mi/mi-var-rtti/gdb.log:2568:==4158350== definitely lost: 435,427 bytes in 15,507 blocks
./gdb/testsuite/outputs/gdb.mi/mi-catch-cpp-exceptions/gdb.log:1704:==4119722== definitely lost: 435,405 bytes in 15,510 blocks
./gdb/testsuite/outputs/gdb.mi/mi-vla-fortran/gdb.log:768:==4113266== definitely lost: 508,585 bytes in 18,109 blocks
With the fix:
./gdb/testsuite/outputs/gdb.base/fork-running-state/gdb.log:1536:==2924193== indirectly lost: 13,848 bytes in 98 blocks
./gdb/testsuite/outputs/gdb.base/fork-running-state/gdb.log:1675:==2928777== indirectly lost: 13,848 bytes in 98 blocks
./gdb/testsuite/outputs/gdb.python/py-inferior-leak/gdb.log:4729:==3353335== definitely lost: 3,360 bytes in 140 blocks
./gdb/testsuite/outputs/gdb.base/kill-detach-inferiors-cmd/gdb.log:210:==2746927== indirectly lost: 13,246 bytes in 154 blocks
./gdb/testsuite/outputs/gdb.base/inferior-clone/gdb.log:179:==3034984== indirectly lost: 12,921 bytes in 161 blocks
./gdb/testsuite/outputs/gdb.base/interrupt-daemon/gdb.log:209:==3006248== indirectly lost: 20,683 bytes in 174 blocks
./gdb/testsuite/outputs/gdb.threads/watchpoint-fork/gdb.log:714:==3512403== indirectly lost: 20,707 bytes in 175 blocks
./gdb/testsuite/outputs/gdb.threads/watchpoint-fork/gdb.log:962:==3514498== indirectly lost: 20,851 bytes in 178 blocks
./gdb/testsuite/outputs/gdb.base/multi-forks/gdb.log:336:==2585839== indirectly lost: 53,630 bytes in 386 blocks
./gdb/testsuite/outputs/gdb.base/multi-forks/gdb.log:1338:==2592417== indirectly lost: 100,008 bytes in 1,154 blocks
Approved-By: Simon Marchi <simon.marchi@efficios.com>
valgrind reports a leak when assigning a gdb_environ to another gdb_environ.
The memory allocated for the target gdb_environ env variables is not released.
The gdb_environ selftest reproduces the leak (see below).
Fix the leak by clearing the target gdb_environ before std::move-ing the
members.
Tested natively and re-running all tests under valgrind.
==3261873== 4,842 bytes in 69 blocks are definitely lost in loss record 6,772 of 6,839
==3261873== at 0x483979B: malloc (vg_replace_malloc.c:393)
==3261873== by 0x25A454: xmalloc (alloc.c:57)
==3261873== by 0x7D1E4E: xstrdup (xstrdup.c:34)
==3261873== by 0x7E2A51: gdb_environ::from_host_environ() (environ.cc:56)
==3261873== by 0x66F1C8: test_reinit_from_host_environ (environ-selftests.c:78)
==3261873== by 0x66F1C8: selftests::gdb_environ_tests::run_tests() (environ-selftests.c:285)
==3261873== by 0x7EFC43: operator() (std_function.h:622)
=
Approved-By: Simon Marchi <simon.marchi@efficios.com>
Some class members were changed to bool, but there was
still some assignments or comparisons using 0/1.
Approved-By: Simon Marchi <simon.marchi@efficios.com>
Consider the executable from test-case gdb.base/interrupt-daemon.exp.
When starting it using gdbserver:
...
$ ./build/gdbserver/gdbserver localhost:2345 \
./outputs/gdb.base/interrupt-daemon/interrupt-daemon
...
and connecting to it using gdb:
...
$ gdb -q -ex "target remote localhost:2345" \
-ex "set follow-fork-mode child" \
-ex "break daemon_main" -ex cont
...
we are setup to do the same as in the test-case: interrupt a running inferior
using ^C.
So let's try:
...
(gdb) continue
Continuing.
^C
...
After pressing ^C, nothing happens. This a known problem, filed as
PR remote/18772.
The problem is that in linux_process_target::request_interrupt, a kill is used
to send a SIGINT, but it fails. And it fails silently.
Make the failure verbose by adding a warning, such that the gdbserver output
becomes more helpful:
...
Process interrupt-daemon created; pid = 15068
Listening on port 2345
Remote debugging from host ::1, port 35148
Detaching from process 15068
Detaching from process 15085
gdbserver: Sending SIGINT to process group of pid 15068 failed: \
No such process
...
Note that the failure can easily be reproduced using the test-case and target
board native-gdbserver:
...
(gdb) continue^M
Continuing.^M
PASS: gdb.base/interrupt-daemon.exp: fg: continue
^CFAIL: gdb.base/interrupt-daemon.exp: fg: ctrl-c stops process (timeout)
...
as reported in PR server/23382.
Tested on x86_64-linux.
Approved-By: Simon Marchi <simon.marchi@efficios.com>
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.
If we instrument cc-with-tweaks.sh to remove the .gnu_debugaltlink file after
dwz has created it, with test-case
gdb.threads/access-mem-running-thread-exit.exp and target board cc-with-dwz-m
we run into:
...
(gdb) file access-mem-running-thread-exit^M
Reading symbols from access-mem-running-thread-exit...^M
could not find '.gnu_debugaltlink' file for access-mem-running-thread-exit^M
...
followed a bit later by:
...
(gdb) file access-mem-running-thread-exit^M
Reading symbols from access-mem-running-thread-exit...^M
gdb/dwarf2/read.c:7284: internal-error: create_all_units: \
Assertion `per_objfile->per_bfd->all_units.empty ()' failed.^M
...
The problem is that create_units does not catch the error thrown by
dwarf2_get_dwz_file.
Fix this by catching the error and performing the necessary cleanup, getting
the same result for the first and second file command.
PR symtab/29805
Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=29805
xrefautomaticsectiontitle appears to be available from texinfo 5.0 or
greater. As such, it is not worthwhile to add requirement for a minimum
necessary makeinfo version. So remove the usage of it.
Also align node name with section title where possible.
ChangeLog:
* libsframe/doc/sframe-spec.texi: Remove usage of
xrefautomaticsectiontitle.
Move all the remaining tests to a single test_break proc. It's a bit
big, but all of these are kind of tied together. The procs starts by
setting breakpoints, checks that we can see them in "info breakpoints",
and tries stopping on them.
Move all the "set bp_locationX" calls together at the top.
Change-Id: Id05f98957e1a3462532d2dbd577cd0a7c7263900
Approved-By: Kevin Buettner <kevinb@redhat.com>
Leave setting bp_location11 in the global scope, so that it's accessible
to other procs.
Change-Id: I8928f01640d3a1e993649b2168b9eda0724ee1d9
Approved-By: Kevin Buettner <kevinb@redhat.com>
One special thing here is that the part just above this one, that sets
catchpoints and verifies they are not hit, requires that we resume
execution to verify that the catchpoints are indeed not hit. I guess
it was previously achieved by the until command, but it doesn't happen
now that the until is moved into test_break_default. Add a
gdb_continue_to_end after setting the catchpoints. If any catchpoint
were to be hit, it would catch the problem.
Change-Id: I5d4b43da91886b1beda9f6e56b05aa04331a9c05
Approved-By: Kevin Buettner <kevinb@redhat.com>
This one is a bit tricky. The clear tests seem to depend on the various
breakpoints that have been set before, starting with the "silent"
breakpoints. So, move all this in a single chunk, it can always be
split later if needed.
Change-Id: I7ba61a5b130ade63eda0c4790534840339f8a72f
Approved-By: Kevin Buettner <kevinb@redhat.com>
This one is already in a proc, just make the proc use proc_with_prefix,
for consistency.
Change-Id: I313ecf5097ff04526c29396529baeba84e37df5a
Approved-By: Kevin Buettner <kevinb@redhat.com>
First of all make operand_type_register_match() apply to all sized
operands, i.e. in Intel Syntax also to respective memory ones. This
addresses gas wrongly accepting certain SIMD insns where register and
memory operand sizes should match but don't. This apparently has
affected all templates with one memory-only operand and one or more
register ones, both permitting at least two sizes, due to CheckRegSize
not taking effect.
Then also add CheckRegSize to a couple of non-SIMD templates matching
that same pattern of memory-only vs register operands. This replaces
bogus (for Intel Syntax) diagnostics referring to a wrong suffix (when
none was used at all) by "type mismatch" ones, just like already emitted
for insns where the template allows a register operand alongside a
memory one at any particular position.
This also is a prereq to limiting (ideally eliminating in the long run)
suffix "derivation" in Intel Syntax mode.
While making the code adjustment also flip order of checks to do the
cheaper one first in both cases.
To properly and predictably determine operand size encoding (operand
size or REX.W prefixes), consistent operand sizes need to be specified.
Add CheckRegSize where this was previously missing.
Both uniformly only ever take 16-bit memory operands while at the same
time requiring matching (in size) register operands, which then also
should disassemble that way. This in particular requires splitting each
of the templates for the assembler and separating decode of the
register and memory forms in the disassembler.
Mode/reg bits for these insns are 000 Dy, 001 Ay, and 111 100 for the
move immediate.
* m68k-opc.c (m68k_opcodes): Only accept 000 and 001 as mode
for move reg to macsr/mask insns.
For v8m, the EXC_RETURN pattern, without security extension, consists of
FType, Mode and SPSEL. These are the same bits that are used in v7m.
This patch extends the list of patterns to include also the FType bit
and not just Mode and SPSEL bits for v8m targets without security
extension.
Signed-off-by: Torbjörn SVENSSON <torbjorn.svensson@foss.st.com>
This extends the commit 4581a1c7d3 fix to more targets, which
hardens BFD a little. I think the real underlying problem was the
bfd_canonicalize_reloc call in load_specific_debug_section which
passed a NULL for "symbols". Fix that too.
PR 22509
bfd/
* aoutx.h (swap_ext_reloc_out): Gracefully handle NULL symbols.
* i386lynx.c (swap_ext_reloc_out): Likewise.
* pdp11.c (pdp11_aout_swap_reloc_out): Likewise.
* coff-tic30.c (reloc_processing): Likewise.
* coff-tic4x.c (tic4x_reloc_processing): Likewise.
* coff-tic54x.c (tic54x_reloc_processing): Likewise.
* coff-z80.c (reloc_processing): Likewise.
* coff-z8k.c (reloc_processing): Likewise.
* ecoff.c (ecoff_slurp_reloc_table): Likewise.
* som.c (som_set_reloc_info): Likewise.
binutils/
* objdump.c (load_specific_debug_section): Pass syms to
bfd_canonicalize_reloc.
If tdata->symbols is NULL, make tdata->symcount zero too. This makes
wasm_get_symtab_upper_bound return the proper result and stops
cascading errors.
* wasm-module.c (wasm_scan_name_function_section): Clear
tdata->symcount on error.
On powerpc64le-linux I ran into this FAIL:
...
(gdb) p exceptions.throw_function()^M
terminate called after throwing an instance of 'int'^M
^M
Program received signal SIGABRT, Aborted.^M
0x00007ffff7979838 in raise () from /lib64/libc.so.6^M
The program being debugged was signaled while in a function called from GDB.^M
GDB remains in the frame where the signal was received.^M
To change this behavior use "set unwindonsignal on".^M
Evaluation of the expression containing the function^M
(SimpleException::throw_function()) will be abandoned.^M
When the function is done executing, GDB will silently stop.^M
(gdb) FAIL: gdb.cp/gdb2495.exp: call a function that raises an exception \
without a handler.
...
The following happens:
- we start an inferior call
- an internal breakpoint is set on the global entry point of std::terminate
- the inferior call uses the local entry point
- the breakpoint is not triggered
- we run into std::terminate
We can fix this by simply adding the missing gdbarch_skip_entrypoint call in
create_std_terminate_master_breakpoint, but we try to do this a bit more
generic, by:
- adding a variant of function create_internal_breakpoint which takes a
minimal symbol instead of an address as argument
- in the new function:
- using both gdbarch_convert_from_func_ptr_addr and gdbarch_skip_entrypoint
- documenting why we don't need to use gdbarch_addr_bits_remove
- adding a note about possibly
needing gdbarch_deprecated_function_start_offset.
- using the new function in:
- create_std_terminate_master_breakpoint
- create_exception_master_breakpoint_hook, which currently uses only
gdbarch_convert_from_func_ptr_addr.
Note: we could use the new function in more locations in breakpoint.c, but
as we're not aware of any related failures, we declare this out of scope for
this patch.
Tested on x86_64-linux, powerpc64le-linux.
Co-Authored-By: Ulrich Weigand <uweigand@de.ibm.com>
Tested-by: Carl Love <cel@us.ibm.com>
PR tdep/29793
Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=29793
According to the riscv psabi, R_RISCV_SUB6 only allows 6 least significant
bits are valid, but since binutils implementation, we usually get 8 bits
field for it. That means, the high 2 bits could be other field and have
different purpose. Therefore, we should filter the 8 bits to 6 bits before
calculate, and then only encode the valid 6 bits back. By the way, we also
need the out-of-range check for R_RISCV_SUB6, and the overflow checks for
all R_RISCV_ADD/SUB/SET relocations, but we can add them in the future patches.
Passing riscv-gnu-toolchain regressions.
bfd/ChangeLog:
* elfnn-riscv.c (riscv_elf_relocate_section): Take the R_RISCV_SUB6
lower 6 bits as the significant bit.
* elfxx-riscv.c (riscv_elf_add_sub_reloc): Likewise.
This uses custom collect/supply regset handlers which pass the TLS
register number from the gdbarch_tdep as the base register number.
Approved-By: Simon Marchi <simon.marchi@efficios.com>
