math: static init order problem
Description
Currently, the AD tape initialisation is prone to the static init order catastrophe. This surfaced during the development of PyStan and leads to a segfault.
Example
The problem is that we require in the init() method of AutodiffStackSingleton that the pointer to ad instance has been initialised, since we check there if the pointer is equal to nullptr. Thus, whenever the pointer to the (optionally thread local) AD tape is not yet initialised, then we run into the static init order problem.
As a solution we need to avoid the double use of the instance_ pointer. Right now it flags “is not initialised” and it points to the instance we use in the thread when initialised.
Expected Output
Our library should not be prone to the static init order problem.
A workaround for C++ users right now is to compile Stan-math with STAN_MATH_REV_CORE_INIT_CHAINABLESTACK_HPP being defined. In that case no initialisation is kicked off by our includes. Instead, the C++ user must initialise himself the AD tape at a point in the program when all linked symbols are initialised.
Current Version:
v2.20.0
About this issue
- Original URL
- State: closed
- Created 5 years ago
- Comments: 58 (30 by maintainers)
@wds15 I should be able to test things after 2.21 is released. (Although getting httpstan to build in a non-header-only way is going to take a fair amount of time.)
We’ve (me and @ahartikainen) decided to delay releasing PyStan 2.20 in the hopes that we might be able to fix this problem. I think our main worry is that some people have started using features which require STAN_THREADS (with PyStan 2.19) and abandoning them would be unfortunate.
@wds15 I think it will be easy to get you an environment in which to test things. Have you used Python a fair amount before? (It might be easier if we did this over chat or video conference with chat.)