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
Port silu_backward to structured #58661
Conversation
[ghstack-poisoned]
💊 CI failures summary and remediationsAs of commit e463470 (more details on the Dr. CI page and at hud.pytorch.org/pr/58661):
🕵️ 3 new failures recognized by patternsThe following CI failures do not appear to be due to upstream breakages: pytorch_linux_xenial_py3_6_gcc5_4_build (1/3)Step: "(Optional) Merge target branch" (full log | diagnosis details | 🔁 rerun)
|
@ezyang has imported this pull request. If you are a Facebook employee, you can view this diff on Phabricator. |
I removed dispatch: CompositeImplicitAutograd: math_silu_backward Definitely not right, but I don't know how it works with structured core. Keeping it will trigger an assertion failure ``` assert dispatch.keys() != {DispatchKey.CompositeImplicitAutograd}, \ f"unexpected name for singleton CompositeImplicitAutograd dispatch entry: expected {cpp.name(func)} " \ f"but got {dispatch[DispatchKey.CompositeImplicitAutograd]}. Rename your implementation to the expected " \ "name, then delete the dispatch table" ``` Differential Revision: [D28572530](https://our.internmc.facebook.com/intern/diff/D28572530) [ghstack-poisoned]
ghstack-source-id: 7b94c707ec5366d05219adf6e0756283c516ec9d Pull Request resolved: #58661
Differential Revision: [D28572530](https://our.internmc.facebook.com/intern/diff/D28572530) [ghstack-poisoned]
Differential Revision: [D28572530](https://our.internmc.facebook.com/intern/diff/D28572530) [ghstack-poisoned]
ghstack-source-id: 51c401833df5c1c18caa0f6b82808e1ccb97c76b Pull Request resolved: #58661
@ezyang has imported this pull request. If you are a Facebook employee, you can view this diff on Phabricator. |
Differential Revision: [D28572530](https://our.internmc.facebook.com/intern/diff/D28572530) [ghstack-poisoned]
Differential Revision: [D28572530](https://our.internmc.facebook.com/intern/diff/D28572530) [ghstack-poisoned]
ghstack-source-id: 630aaef898ffb726316e14072a11a900dc73d526 Pull Request resolved: #58661
@ezyang Do you know how structured functions work with CompositeImplicitAutograd? I looked into the code base and there doesn't seem to be any examples of it working together at the moment. Any suggestions are greatly appreciated! |
They don't. See #50953 The workaround is to NOT use structured, and just redispatch as necessary. |
Sorry, I didn't make that clear. I know that currently CompositeImplicitAutograd and Structured Core don't work together. But I don't know how to handle the following error.
How do I preserve the original functionality of math_silu_backward? Any suggestions are greatly appreciated! |
@ezyang has imported this pull request. If you are a Facebook employee, you can view this diff on Phabricator. |
OHHH you're right, this is different, I think you might need a teeny bugfix for this one |
but also need #58569 |
Differential Revision: [D28572530](https://our.internmc.facebook.com/intern/diff/D28572530) [ghstack-poisoned]
ghstack-source-id: a30d9f07b401da481b515612a466e4344bbe2341 Pull Request resolved: #58661
@ezyang has imported this pull request. If you are a Facebook employee, you can view this diff on Phabricator. |
Differential Revision: [D28572530](https://our.internmc.facebook.com/intern/diff/D28572530) [ghstack-poisoned]
ghstack-source-id: 41417bfe769cbd5f58ed6cb7e76203cfb5d87660 Pull Request resolved: #58661
@ezyang has imported this pull request. If you are a Facebook employee, you can view this diff on Phabricator. |
it would seem the asan failure are real |
successfully reproduced locally |
fix coming |
#58661 induced a static initialization order fiasco as flagged by ASAN strict_init_order=true. On further inspection, it became clear that it was not necessary for these to actually be globals initialized at module load time; so I converted them into Meyer singletons which ensures they get loaded immediately when another compilation unit requests them. Signed-off-by: Edward Z. Yang <ezyang@fb.com> [ghstack-poisoned]
#58661 induced a static initialization order fiasco as flagged by ASAN strict_init_order=true. On further inspection, it became clear that it was not necessary for these to actually be globals initialized at module load time; so I converted them into Meyer singletons which ensures they get loaded immediately when another compilation unit requests them. Signed-off-by: Edward Z. Yang <ezyang@fb.com> [ghstack-poisoned]
#58661 induced a static initialization order fiasco as flagged by ASAN strict_init_order=true. On further inspection, it became clear that it was not necessary for these to actually be globals initialized at module load time; so I converted them into Meyer singletons which ensures they get loaded immediately when another compilation unit requests them. Signed-off-by: Edward Z. Yang <ezyang@fb.com> [ghstack-poisoned]
#58661 induced a static initialization order fiasco as flagged by ASAN strict_init_order=true. On further inspection, it became clear that it was not necessary for these to actually be globals initialized at module load time; so I converted them into Meyer singletons which ensures they get loaded immediately when another compilation unit requests them. Signed-off-by: Edward Z. Yang <ezyang@fb.com> ghstack-source-id: abca5df9cfd71f769509c05c853611a2682e68e8 Pull Request resolved: #60568
Thank you very much! Can you share your debugging experience? |
In this particular case, I spent a day getting a local ASAN build and confirming that it indeed failed. (Mostly by staring at https://github.com/pytorch/pytorch/blob/master/.jenkins/pytorch/build-asan.sh and https://github.com/pytorch/pytorch/blob/master/.jenkins/pytorch/test.sh ) With debug info, I could get line numbers for this error in CI:
First I had to remind myself what this error message meant. So I looked for the meaning of this error at https://github.com/google/sanitizers/wiki/AddressSanitizerInitializationOrderFiasco#strict-init-order-checking Then I looked at the code, and tried to figure out what static data |
Summary: Pull Request resolved: #60568 #58661 induced a static initialization order fiasco as flagged by ASAN strict_init_order=true. On further inspection, it became clear that it was not necessary for these to actually be globals initialized at module load time; so I converted them into Meyer singletons which ensures they get loaded immediately when another compilation unit requests them. Signed-off-by: Edward Z. Yang <ezyang@fb.com> Test Plan: Imported from OSS Reviewed By: bdhirsh Differential Revision: D29338019 Pulled By: ezyang fbshipit-source-id: 282846118df6867277404a1830d0ce39fccaa769
Differential Revision: [D28572530](https://our.internmc.facebook.com/intern/diff/D28572530) [ghstack-poisoned]
ghstack-source-id: 763e15f79779482887f9bfa2d2472b1714bf8bcc Pull Request resolved: #58661
@ezyang has imported this pull request. If you are a Facebook employee, you can view this diff on Phabricator. |
Stack from ghstack:
Differential Revision: D28572530