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".
