Suprious backtrace-native test failures on ubuntu package builders

[Mark Wielaard <mjw at redhat dot com>]

Hi Matthias, elfutils hackers,

The ubuntu package builders sometimes see failures in backtrace-native
and/or backtrace-native-biarch tests. The failures comes from an assert
in tests/backtrace.c (see_exec_module):

struct see_exec_module
{
  Dwfl_Module *mod;
  char selfpath[PATH_MAX + 1];
};

static int
see_exec_module (Dwfl_Module *mod, void **userdata __attribute__ ((unused)),
                 const char *name __attribute__ ((unused)),
                 Dwarf_Addr start __attribute__ ((unused)), void *arg)
{
  struct see_exec_module *data = arg;
  if (strcmp (name, data->selfpath) != 0)
    return DWARF_CB_OK;
  assert (data->mod == NULL);
  data->mod = mod;
  return DWARF_CB_OK;
}

The assert makes sure that we only see one one module with the same
"selfpath". The selfpath is setup as follows:

  char *selfpathname;
  int i = asprintf (&selfpathname, "/proc/%ld/exe", (long) pid);
  assert (i > 0);
  size_t ssize = (selfpathname, data.selfpath,
                  sizeof (data.selfpath));
  free (selfpathname);
  assert (ssize > 0 && ssize < (ssize_t) sizeof (data.selfpath));
  data.selfpath[ssize] = '\0';
  data.mod = NULL;
  ptrdiff_t ptrdiff = dwfl_getmodules (dwfl, see_exec_module, &data, 0);
  assert (ptrdiff == 0);
  assert (data.mod != NULL);

The dwfl is setup with dwfl_linux_proc_report (dwfl, pid).
So it could be a bug in our /proc/PID/maps reader. But it could also
be that for some reason the exec file is actually mapped twice and
two separate Dwfl_Modules are created for it.

I have been unable to recreate the failure and so don't really understand
what is going wrong. Has anybody else seen a failure with backtrace-native
and/or backtrace-native-biarch in see_exec_module?

This is probably the wrong place to do this sanity check and we should
have a separate testcase for it, so it is clearer why/what is going
wrong/tested. It probably would also be a good idea to add a
dwfl_mainmodule () function that gives you the main exec or kernel
module since this is something people seem to often want. In this case
we really just want the first Dwfl_Module with the given path anyway
and we could just remove the assert and skip further probing once we
find the requested main module.

But before we do it would be good to understand why the failure is
happening. Matthias, would you be able to replicate the issue somehow
with the attached patch added to give us a bit more information?

Thanks,

Mark

Attachment: see_exec_module.patch
Description: Text document