This is an archive of the discontinued LLVM Phabricator instance.

[Asan] Attempt to fix for FreeBSD
AbandonedPublic

Authored by devnexen on May 28 2018, 3:42 AM.

Details

Summary

After several different approaches, asan hangs at AsanTSDInit, thus choosing a similar workflow as fuschia for example. Keeping the current workflow for other oses.

Diff Detail

Event Timeline

devnexen created this revision.May 28 2018, 3:42 AM
Herald added subscribers: Restricted Project, llvm-commits, kubamracek. · View Herald TranscriptMay 28 2018, 3:42 AM

NetBSD is also affected. We shall go for a shared solution at least between BSDs and Linux.

A similar problem is in MSan, HWMSan etc.

NetBSD is also affected. We shall go for a shared solution at least between BSDs and Linux.

A similar problem is in MSan, HWMSan etc.

I would say BSD at first, Linux works fine and this solution would probably not satisfy Linux anyway (e.g. lsan for example).
I can extend to NetBSD no worries as long you re ok with this solution.

Apart of this is the MSan issue particular to NetBSD and what sort of issue is it ? e.g. it works relatively ok under FreeBSD.

devnexen updated this revision to Diff 150048.Jun 5 2018, 3:00 PM

Using thread local solution for NetBSD and FreeBSD, keeping pthread_key_create and such for Linux and Solaris.

@krytarowski What do you think of this approach ? I ve tried several approaches to keep pthread_key_create/pthread_getspecific/pthread_setspecific but did not work out.

I'm not sure whether this is equivalent.

I have a local patch to intercept _lwp_exit(2) and call destructor from this level. But I'm swamped by more serious issues like now, so I'm have scheduled it for later.

I'm not sure whether this is equivalent.

I have a local patch to intercept _lwp_exit(2) and call destructor from this level. But I'm swamped by more serious issues like now, so I'm have scheduled it for later.

I understand. As long it s before August :)

devnexen abandoned this revision.Jul 1 2018, 11:09 AM

BTW, how did you figure out it dead locked in __asan_init?

I used clang++ -fsanitize=address -Wl,-dynamic-linker,/tmp/c/libexec/ld-elf.so.1 -Wl,-R,/tmp/c/lib -xc =(printf 'int main(){}') -o aa
where ld-elf.so.1 and libthr.so.3 and their debug info were extracted from FreeBSD 12.0-CURRENT snapshot base.txz and base-dbg.txz.

The gdb aa terminal was unresponsive so I had to pkill -STOP aa in another shell. Then I could print the backtrace of the aa process.

No debug info for me I worked at that time only with release versions but having ported softwares to FreeBSD I knew how libpthread is "delicate".

Fixed for FreeBSD? There is still a problem for NetBSD, but I'm still swamped with other things.

Fixed for FreeBSD? There is still a problem for NetBSD, but I'm still swamped with other things.

Fixed for FreeBSD 12.0-CURRENT (which lives in my qemu :( ). Other have told me OpenBSD is good. What's the issue for NetBSD?

Fixed for FreeBSD? There is still a problem for NetBSD, but I'm still swamped with other things.

Fixed for FreeBSD 12.0-CURRENT (which lives in my qemu :( ). Other have told me OpenBSD is good. What's the issue for NetBSD?

pthread functions are called too early, before initialization of the threading library

Fixed for FreeBSD? There is still a problem for NetBSD, but I'm still swamped with other things.

Fixed for FreeBSD 12.0-CURRENT (which lives in my qemu :( ). Other have told me OpenBSD is good. What's the issue for NetBSD?

pthread functions are called too early, before initialization of the threading library

When you will have more time we can reexamine this fix or at least takng inspiration from if you wish.