You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
The non-strict order mode relies on the fact that all __asan_register_globals() calls
will occur before the dynamic initialization of the globals, so that the tool will
know about every global before trying to initialize anything.
This assumption is broken on Darwin, because the linker does not support static constructor
priorities across translation units, and usually _all_ the static constructors from
a certain module will be executed before moving on to a next module.
This means that the only way to use the init-order checker on Darwin is to run it in
the strict_init_order=true mode, which is prone to false positives (Alexey, please
correct me if I'm wrong)
There are several things we can do about this:
1. Declare strict_init_order=true the default (or the only possible) option on Darwin.
2. Declare the init-order-checker broken on Darwin.
3. Create a section with appending linkage that contains pointers to ASan's per-module
constructors. Once any of those is executed, it calls every other constructors. This
way we'll make sure ASan constructors are executed before others (we still won't have
full support for constructor priorities, but we don't actually need it).
Reported by ramosian.glider on 2013-05-17 12:53:07
The text was updated successfully, but these errors were encountered:
As the folks have pointed out in an offline chat today, the problem applies to addressability
checking in globals as well as init order checking.
For example, it may turn out that a static constructor of one module may access a global
array from another module out of its bounds. If this happens before that global array
is registered (which is possible on Darwin), ASan won't report the error.
Reported by ramosian.glider on 2013-05-20 17:51:35
This is partially addressed by D16737 since it registers all globals across all TUs simultaneously, but it does not guarantee (as far as I can tell) that this happens before any other constructor executes.
Originally reported on Google Code with ID 186
Reported by
ramosian.glider
on 2013-05-17 12:53:07The text was updated successfully, but these errors were encountered: