Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Add patches for MSAN #11

Merged
merged 3 commits into from
Aug 23, 2022
Merged

Add patches for MSAN #11

merged 3 commits into from
Aug 23, 2022

Conversation

gbaraldi
Copy link
Member

Patches to make MSAN happy/work, as mentioned in JuliaLang/julia#46349.

@Keno

vitalybuka and others added 3 commits August 22, 2022 13:16
Insts must be destroyd before xParent
or it can read it with stack like this:
   0 in llvm::MachineInstr::getMF() const MachineInstr.cpp:637:3
   1 in getMF MachineInstr.h:302:50
   2 in removeNodeFromList MachineBasicBlock.cpp:163:32
Copy link
Member

@Keno Keno left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@vchuravy when you build the version based on this, can you make sure to also build x86_64-linux-gnu-sanitize+memory, so we don't have to go through the process twice?

@vchuravy vchuravy merged this pull request into JuliaLang:julia-release/14.x Aug 23, 2022
stahta01 pushed a commit to stahta01/llvm-project that referenced this pull request Feb 9, 2023
We experienced some deadlocks when we used multiple threads for logging
using `scan-builds` intercept-build tool when we used multiple threads by
e.g. logging `make -j16`

```
(gdb) bt
#0  0x00007f2bb3aff110 in __lll_lock_wait () from /lib/x86_64-linux-gnu/libpthread.so.0
JuliaLang#1  0x00007f2bb3af70a3 in pthread_mutex_lock () from /lib/x86_64-linux-gnu/libpthread.so.0
JuliaLang#2  0x00007f2bb3d152e4 in ?? ()
JuliaLang#3  0x00007ffcc5f0cc80 in ?? ()
JuliaLang#4  0x00007f2bb3d2bf5b in ?? () from /lib64/ld-linux-x86-64.so.2
JuliaLang#5  0x00007f2bb3b5da27 in ?? () from /lib/x86_64-linux-gnu/libc.so.6
JuliaLang#6  0x00007f2bb3b5dbe0 in exit () from /lib/x86_64-linux-gnu/libc.so.6
JuliaLang#7  0x00007f2bb3d144ee in ?? ()
JuliaLang#8  0x746e692f706d742f in ?? ()
JuliaLang#9  0x692d747065637265 in ?? ()
JuliaLang#10 0x2f653631326b3034 in ?? ()
JuliaLang#11 0x646d632e35353532 in ?? ()
JuliaLang#12 0x0000000000000000 in ?? ()
```

I think the gcc's exit call caused the injected `libear.so` to be unloaded
by the `ld`, which in turn called the `void on_unload() __attribute__((destructor))`.
That tried to acquire an already locked mutex which was left locked in the
`bear_report_call()` call, that probably encountered some error and
returned early when it forgot to unlock the mutex.

All of these are speculation since from the backtrace I could not verify
if frames 2 and 3 are in fact corresponding to the `libear.so` module.
But I think it's a fairly safe bet.

So, hereby I'm releasing the held mutex on *all paths*, even if some failure
happens.

PS: I would use lock_guards, but it's C.

Reviewed-by: NoQ

Differential Revision: https://reviews.llvm.org/D118439

(cherry picked from commit d919d02)
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

4 participants