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

Trouble to compile Firefox/ASan on Mountain Lion #95

Closed
ramosian-glider opened this issue Aug 31, 2015 · 14 comments
Closed

Trouble to compile Firefox/ASan on Mountain Lion #95

ramosian-glider opened this issue Aug 31, 2015 · 14 comments

Comments

@ramosian-glider
Copy link
Member

Originally reported on Google Code with ID 95

I am trying to compile Firefox "trunk" with ASan support on Mountain Lion but without
success. I have tried the following LLVM revisions: r160364, r158863, r161107 but the
error persists.

Compiling the same Firefox version on Mountain Lion with the default clang compiler
"Apple clang version 4.0 (tags/Apple/clang-421.0.57) (based on LLVM 3.1svn)" works
without any problems. 
The same applies for compiling Firefox with ASan support on Lion, which worked also
without problems.

Please see the attached config.log for more information. Let me know if you need further
information.

Reported by cdiehl.4 on 2012-08-01 12:06:00


- _Attachment: [config.log](https://storage.googleapis.com/google-code-attachments/address-sanitizer/issue-95/comment-0/config.log)_
@ramosian-glider
Copy link
Member Author

Have you tried building Firefox with the ToT Clang without ASan (i.e. remove the -faddress-sanitizer
from the compiler and linker flags)?
Looking at the log I suppose that these errors are specific to the Clang version you
are using.

Reported by ramosian.glider on 2012-08-01 12:11:00

  • Labels added: OpSys-OSX

@ramosian-glider
Copy link
Member Author

That seems to work, it passed the location where the error occurred before. Thanks!

Reported by cdiehl.4 on 2012-08-01 12:19:17

@ramosian-glider
Copy link
Member Author

If that is working, then the error must be ASan specific. Unfortunately I don't have
any system yet to reproduce that. Maybe you could also attach the regular output during
the failing compile run? (the config.log is quite confusing to me as there's so much
additional info in there)

Reported by decoder.oh on 2012-08-01 12:25:08

@ramosian-glider
Copy link
Member Author

So am I right that you are able to build Firefox using trunk Clang without ASan, but
the configuration phase fails with ASan?
Which of the compilation failures in the log are critical for the configuration? Is
it possible to reproduce them apart of the Firefox compilation?

Reported by ramosian.glider on 2012-08-01 12:26:03

@ramosian-glider
Copy link
Member Author

.mozconfig: http://cdiehl.pastebin.mozilla.org/1729401

Yes, I am able to compile Firefox with trunk Clang. I have attached the normal build
log too.

Reported by cdiehl.4 on 2012-08-01 12:34:43


- _Attachment: [build_log_plain.txt](https://storage.googleapis.com/google-code-attachments/address-sanitizer/issue-95/comment-5/build_log_plain.txt)_

@ramosian-glider
Copy link
Member Author

A compact version of the above output: http://cdiehl.pastebin.mozilla.org/1727772

Reported by cdiehl.4 on 2012-08-01 12:39:03

@ramosian-glider
Copy link
Member Author

Looks like the problem is mach_override not working on some OS X library. I am checking
what the missing instructions are.

Reported by rafael.espindola on 2012-08-01 14:45:04

@ramosian-glider
Copy link
Member Author

I have just sent a pull request upstream fixing it:

https://github.com/rentzsch/mach_star/pulls

Reported by rafael.espindola on 2012-08-01 15:36:15

@ramosian-glider
Copy link
Member Author

We're using a fork of mach_override which is very much different from Jonathan's code
now (for example we're dealing with the allocateBranchIsland speed issue). I'll commit
your change into LLVM. 

Reported by ramosian.glider on 2012-08-01 15:52:05

@ramosian-glider
Copy link
Member Author

Rafael, I've committed your patch (Clang r161116), but some ASan tests still fail on
10.8. Taking a look.

Reported by ramosian.glider on 2012-08-01 16:37:28

@ramosian-glider
Copy link
Member Author

Looks like the only two failing tests rely on an incorrect assumption about strcpy/strncpy
behavior (see issue 96), so basic ASan functionality should work on Mountain Lion as
of r161116.

@cdiehl.4: can you please verify this?

Reported by ramosian.glider on 2012-08-01 16:58:45

  • Status changed: Started

@ramosian-glider
Copy link
Member Author

Works again, thanks!

Reported by cdiehl.4 on 2012-08-01 17:52:46

@ramosian-glider
Copy link
Member Author

Reported by ramosian.glider on 2012-08-02 07:55:33

  • Status changed: Fixed

@ramosian-glider
Copy link
Member Author

Adding Project:AddressSanitizer as part of GitHub migration.

Reported by ramosian.glider on 2015-07-30 09:12:59

  • Labels added: ProjectAddressSanitizer

wanchaol added a commit to pytorch/pytorch that referenced this issue Apr 16, 2020
As we hold a mutex for our custom C++ Node, when calling reentrant
backward from custom C++ function, we will cocurrently holding many
mutexes up to MAX_DEPTH. TSAN only allow 65 mutexes at once, otherwise
it will complain. This PR lower the limit according to TSAN.

TSAN Reference: google/sanitizers#95

[ghstack-poisoned]
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

1 participant