This buildbot has been failing for over a week straight ( http://lab.llvm.org:8011/builders/clang-cmake-mips/builds/9387 ) - does anyone know/care about it?
I do. I’ll take a look.
Is there a way for owners to get emails for long-lasting failures?
I do. I'll take a look.
Is there a way for owners to get emails for long-lasting failures?
I'm not sure what the generic setup is, but at least for the builder/slave
I admin, it emails me on every failure. So I get a lot of mail,
continuously, if there's a consistent failure.
- Dave
I do. I’ll take a look.
Is there a way for owners to get emails for long-lasting failures?
I’m not sure what the generic setup is, but at least for the builder/slave
I admin, it emails me on every failure. So I get a lot of mail, continuously,
if there’s a consistent failure.
Ok, I’ll see if I can get mine to do the same.
I’ve just noticed that this is a new test added in r248325 and has never passed on this builder. Added the author of the test (Evgeniy).
This is quite sad as we can't reliably fix this case with the static
asan runtime.
I've disabled the test on mips.
This is quite sad as we can't reliably fix this case with the static
asan runtime.
I've disabled the test on mips.
Thanks!
Thanks. From the debugging I've done so far it looks like it could be another 32-bit big-endian specific bug. It seems to be segfaulting in the memset() in allocate_stack.c (from glib) because given stack pointer is null. I'm guessing this is because it read the wrong half of a 64-bit value somewhere but I haven't identified where it goes wrong.
The stack trace look very similar to the original problem on
linux/x86, which was due to mismatching symbol versions between
pthread_attr_* calls (unintercepted, binding to the default version)
and pthread_create (intercepted, binding to the lowest version through
dlsym).
That seems to be it, defining ASAN_PTHREAD_CREATE_VERSION to "GLIBC_2.2" fixes the problem. Thanks.
I'll re-enable the test and commit a fix for mips shortly.