Re: Suprious backtrace-native test failures on ubuntu package builders

[Matthias Klose <doko at ubuntu dot com>]

On 12.08.2016 13:14, Mark Wielaard wrote:
> 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?

after a few retries the build succeeded "unfortunately".