Occasional Contributorquartus_map crash, possibly due to shared library shenanigans
Hi,
I keep getting reproducible crashes from quartus_map when called inside a Docker container, and right now I'm at the stage in debugging where I'm wondering how this could ever have worked.
Basically, quartus_map is, for some reason, linked against libtbbmalloc_proxy, which provides malloc/realloc/free and is meant to override these for the entire process. Later, libsys_cpt.so uses
dlopen("libudev.so.1", RTLD_LAZY|RTLD_DEEPBIND);
to get the system libudev, which is then used to scan for connected devices in the hope of finding something uniquely identifiable to attach licensing to. libudev, at several points, calls strdup (which is in libc, but uses malloc from libtbbmalloc_proxy) and realloc (which is in libc, and not overridden because the RTLD_DEEPBIND puts the libc definition first).
Now, since strdup returns a pointer from malloc, it should be safe to call realloc on it, which is what libudev does -- however it tries to use the libc realloc on a pointer that was allocated through libtbbmalloc_proxy, and this falls over in a spectacular fashion:
Info: Command: quartus_map raid
realloc(): invalid pointer
Aborted
Now I have no clue how this could have ever worked, or why that only happens inside Docker -- it should crash everywhere.
I can use LD_PRELOAD to add another gross hack on top:
#define _GNU_SOURCE 1
#include <dlfcn.h>
static void *(*orig_dlopen)(char const *, int) = 0;
void *dlopen(char const *name, int flags)
{
if(!orig_dlopen)
orig_dlopen = dlsym(RTLD_NEXT, "dlopen");
flags &= ~RTLD_DEEPBIND;
return orig_dlopen(name, flags);
}
When I compile this
$ gcc -shared -o /tmp/hack.so hack.c -ldl
and use LD_PRELOAD to inject it into the quartus_map process
LD_PRELOAD=/tmp/hack.so quartus_map raid
then my design (almost) compiles, the remaining problems seem unrelated.
Since this is a wobbly stack of hacks upon hacks, it would be nice if there was a proper solution that doesn't require me to inject code into the Quartus process. Is there a good way to get this bug to the attention of the software team?
