[Bug symtab/31806] New: [gdb/symtab] debuginfod query can fail silently

[Bug symtab/31806] New: [gdb/symtab] debuginfod query can fail silently

[vries at gcc dot gnu.org]

https://sourceware.org/bugzilla/show_bug.cgi?id=31806

            Bug ID: 31806
           Summary: [gdb/symtab] debuginfod query can fail silently
           Product: gdb
           Version: 14.1
            Status: NEW
          Severity: normal
          Priority: P2
         Component: symtab
          Assignee: unassigned at sourceware dot org
          Reporter: vries at gcc dot gnu.org
  Target Milestone: ---

Using a 14.2 based package, I ran into:
...
(gdb) core
/home/abuild/rpmbuild/BUILD/gdb-14.2/build-x86_64-suse-linux/gdb/testsuite.unix.-m64/outputs/gdb.debuginfod/fetch_src_and_symbols/corefile^M
^M
This GDB supports auto-downloading debuginfo from the following URLs:^M
  <http://127.0.0.1:8002>^M
Enable debuginfod for this session? (y or [n]) y^M
Debuginfod has been enabled.^M
To make this setting permanent, add 'set debuginfod enabled on' to .gdbinit.^M
Downloading executable for
/home/abuild/rpmbuild/BUILD/gdb-14.2/build-x86_64-suse-linux/gdb/testsuite.unix.-m64/outputs/gdb.debuginfod/fetch_src_and_symbols/fetch_src_and_symbols2...^M
warning: Can't open file
/home/abuild/rpmbuild/BUILD/gdb-14.2/build-x86_64-suse-linux/gdb/testsuite.unix.-m64/outputs/gdb.debuginfod/fetch_src_and_symbols/fetch_src_and_symbols2
during file-backed mapping note processing^M
[New LWP 11699]^M
Core was generated by
`/home/abuild/rpmbuild/BUILD/gdb-14.2/build-x86_64-suse-linux/gdb/testsuite.unix.'.^M
Program terminated with signal SIGTRAP, Trace/breakpoint trap.^M
#0  0x000055555555468d in ?? ()^M
(gdb) FAIL: gdb.debuginfod/fetch_src_and_symbols.exp: local_url: file corefile
...

AFAICT, everything is going well until the "Downloading" executable message,
issued by this debuginfod_exec_query in core_target::build_file_mappings:
...
            if (expanded_fname == nullptr && build_id != nullptr)
              debuginfod_exec_query (build_id->data, build_id->size,
                                     filename, &expanded_fname);

            if (expanded_fname == nullptr)
              {
                m_core_unavailable_mappings.emplace_back (start, end - start);
                unavailable_paths.insert (filename);
                warning (_("Can't open file %s during file-backed mapping "
                           "note processing"),
                         filename);
                return;
              }
...

But somehow it returns with expanded_fname nullptr, after which we see the
warning.

The query returns a scoped fd, and if it's negative it represents an errno.

If the errno is not ENOENT, the query will have issued a message in
print_outcome:
...
static void
print_outcome (int fd, const char *desc, const char *fname)
{
  if (fd < 0 && fd != -ENOENT)
    {
      ui_file *outstream = get_unbuffered (gdb_stdout);
      gdb_printf (outstream,
                  _("Download failed: %s.  Continuing without %s %ps.\n"),
                  safe_strerror (-fd),
                  desc,
                  styled_string (file_name_style.style (), fname));
    }
}
...

But otherwise, the download fails silently, and you have to read the source
code to understand why.

This is a reasonable default for general usage.

But for test-cases it's useful to be more verbose, to get more info for rare
and hard-to-reproduce fails.

I think this is a reasonable default for

-- 
You are receiving this mail because:
You are on the CC list for the bug.

[Bug symtab/31806] [gdb/symtab] debuginfod query can fail silently

[vries at gcc dot gnu.org]

https://sourceware.org/bugzilla/show_bug.cgi?id=31806

--- Comment #1 from Tom de Vries <vries at gcc dot gnu.org> ---
This patch series improves things somewhat:
https://sourceware.org/pipermail/gdb-patches/2024-May/209428.html

-- 
You are receiving this mail because:
You are on the CC list for the bug.

[Bug symtab/31806] [gdb/symtab] debuginfod query can fail silently

[vries at gcc dot gnu.org]

https://sourceware.org/bugzilla/show_bug.cgi?id=31806

--- Comment #2 from Tom de Vries <vries at gcc dot gnu.org> ---
I think this is another instance of the same problem:
...
(gdb) file
/home/abuild/rpmbuild/BUILD/gdb-14.2/build-x86_64-suse-linux/gdb/testsuite.unix.-m32.-fno-PIE.-no-pie/outputs/gdb.debuginfod/crc_mismatch/crc_mismatch-2^M
Reading symbols from
/home/abuild/rpmbuild/BUILD/gdb-14.2/build-x86_64-suse-linux/gdb/testsuite.unix.-m32.-fno-PIE.-no-pie/outputs/gdb.debuginfod/crc_mismatch/crc_mismatch-2...^M
Downloading separate debug info for
/home/abuild/rpmbuild/BUILD/gdb-14.2/build-x86_64-suse-linux/gdb/testsuite.unix.-m32.-fno-PIE.-no-pie/outputs/gdb.debuginfod/crc_mismatch/crc_mismatch-2...^M
warning: the debug information found in
"/home/abuild/rpmbuild/BUILD/gdb-14.2/build-x86_64-suse-linux/gdb/testsuite.unix.-m32.-fno-PIE.-no-pie/outputs/gdb.debuginfod/crc_mismatch/crc_mismatch-2.debug"
does not match
"/home/abuild/rpmbuild/BUILD/gdb-14.2/build-x86_64-suse-linux/gdb/testsuite.unix.-m32.-fno-PIE.-no-pie/outputs/gdb.debuginfod/crc_mismatch/crc_mismatch-2"
(CRC mismatch).^M
(No debugging symbols found in
/home/abuild/rpmbuild/BUILD/gdb-14.2/build-x86_64-suse-linux/gdb/testsuite.unix.-m32.-fno-PIE.-no-pie/outputs/gdb.debuginfod/crc_mismatch/crc_mismatch-2)^M
(gdb) FAIL: gdb.debuginfod/crc_mismatch.exp: local_debuginfod: debuginfod
running, info downloaded, no CRC mismatch
...

-- 
You are receiving this mail because:
You are on the CC list for the bug.