Bugzilla

(In reply to Jeff Muizelaar [:jrmuizel] from comment #9)
> It looks the failure's only happen on Windows ASAN builds. Is there a weird interaction between ASAN and ACG?

Hello, that is very likely indeed. I'm very confident that ACG should be disabled for ASAN to work properly. Below is an explanation why, showing where I would suggest to dig to confirm exactly why that could produce timeouts.

ASAN relies on a open-source run-time library called `clang_rt.asan*.dll` on Windows. This library contains code that [prepares the environment that Firefox will execute in when built with ASAN](https://github.com/llvm-mirror/compiler-rt/blob/69445f095c22aac2388f939bedebf224a6efcdaf/lib/asan/asan_rtl.cpp#L398). As part of this initialization, [it puts interceptors](https://github.com/llvm-mirror/compiler-rt/blob/69445f095c22aac2388f939bedebf224a6efcdaf/lib/asan/asan_interceptors.cpp#L628) [on various functions](https://github.com/llvm-mirror/compiler-rt/blob/69445f095c22aac2388f939bedebf224a6efcdaf/lib/asan/asan_malloc_win.cpp#L492). [Various strategies are tried for putting interceptors](https://github.com/llvm-mirror/compiler-rt/blob/69445f095c22aac2388f939bedebf224a6efcdaf/lib/interception/interception_win.cpp#L826), but they should all fail with ACG enabled. Moreover some of them could potentially take a very long time to do so. Consider for example [this function](https://github.com/llvm-mirror/compiler-rt/blob/69445f095c22aac2388f939bedebf224a6efcdaf/lib/interception/interception_win.cpp#L316), which will iterate over regions of memory looking for a suitable location where asking allocate RWX memory works, which is something that will always fail with ACG. This may explain the timeouts, although I don't have confirmed practically that this is the exact reason for those.

(In reply to Jeff Muizelaar [:jrmuizel] from comment #9)
> It looks the failure's only happen on Windows ASAN builds. Is there a weird interaction between ASAN and ACG?

Hello, that is very likely indeed. I'm very confident that ACG should be disabled for ASAN to work properly. Below is an explanation why, showing where I would suggest to dig to confirm exactly why that could produce timeouts.

ASAN relies on a open-source run-time library called `clang_rt.asan*.dll` on Windows. This library contains code that [prepares the environment that Firefox will execute in when built with ASAN](https://github.com/llvm-mirror/compiler-rt/blob/69445f095c22aac2388f939bedebf224a6efcdaf/lib/asan/asan_rtl.cpp#L398). As part of this initialization, [it puts interceptors](https://github.com/llvm-mirror/compiler-rt/blob/69445f095c22aac2388f939bedebf224a6efcdaf/lib/asan/asan_interceptors.cpp#L628) [on various functions](https://github.com/llvm-mirror/compiler-rt/blob/69445f095c22aac2388f939bedebf224a6efcdaf/lib/asan/asan_malloc_win.cpp#L492). [Various strategies are tried for putting interceptors](https://github.com/llvm-mirror/compiler-rt/blob/69445f095c22aac2388f939bedebf224a6efcdaf/lib/interception/interception_win.cpp#L826), but they should all fail with ACG enabled. Moreover some of them could potentially take a very long time to do so. Consider for example [this function](https://github.com/llvm-mirror/compiler-rt/blob/69445f095c22aac2388f939bedebf224a6efcdaf/lib/interception/interception_win.cpp#L316), which will iterate over regions of memory looking for a suitable location where asking to allocate RWX memory works, something that will always fail with ACG. This may explain the timeouts, although I don't have confirmed practically that this is the exact reason for those.

(In reply to Jeff Muizelaar [:jrmuizel] from comment #9)
> It looks the failure's only happen on Windows ASAN builds. Is there a weird interaction between ASAN and ACG?

Hello, that is very likely indeed. I'm very confident that ACG should be disabled for ASAN to work properly. Below is an explanation why, showing where I would suggest to dig to confirm exactly why that could produce timeouts.

ASAN relies on a open-source run-time library called `clang_rt.asan*.dll` on Windows. This library contains code that [prepares the environment that Firefox will execute in when built with ASAN](https://github.com/llvm-mirror/compiler-rt/blob/69445f095c22aac2388f939bedebf224a6efcdaf/lib/asan/asan_rtl.cpp#L398). As part of this initialization, [it puts interceptors](https://github.com/llvm-mirror/compiler-rt/blob/69445f095c22aac2388f939bedebf224a6efcdaf/lib/asan/asan_interceptors.cpp#L628) [on various functions](https://github.com/llvm-mirror/compiler-rt/blob/69445f095c22aac2388f939bedebf224a6efcdaf/lib/asan/asan_malloc_win.cpp#L492). [Various strategies are tried for putting interceptors](https://github.com/llvm-mirror/compiler-rt/blob/69445f095c22aac2388f939bedebf224a6efcdaf/lib/interception/interception_win.cpp#L826), but they should all fail with ACG enabled. Moreover some of them could potentially take a very long time to do so. Consider for example [this function](https://github.com/llvm-mirror/compiler-rt/blob/69445f095c22aac2388f939bedebf224a6efcdaf/lib/interception/interception_win.cpp#L316), which will iterate over regions of memory looking for a suitable location where asking to allocate RWX memory works, something that will always fail with ACG. This may explain the timeouts, although I don't have confirmed practically that this is the exact reason for those.

It should be technically possible to make ASAN working if ACG was enabled by the child process itself dynamically (so after ASAN initialization), and not as part of the startup flags for that process, but it's unclear what we would gain by having ACG in ASAN builds.

(In reply to Jeff Muizelaar [:jrmuizel] from comment #9)
> It looks the failure's only happen on Windows ASAN builds. Is there a weird interaction between ASAN and ACG?

Hello, that is very likely indeed. I'm very confident that ACG should be disabled for ASAN to work properly. Below is an explanation why, showing where I would suggest to dig to confirm exactly why that could produce timeouts.

ASAN relies on a open-source run-time library called `clang_rt.asan*.dll` on Windows. This library contains code that [prepares the environment that Firefox will execute in when built with ASAN](https://github.com/llvm-mirror/compiler-rt/blob/69445f095c22aac2388f939bedebf224a6efcdaf/lib/asan/asan_rtl.cpp#L398). As part of this initialization, [it puts interceptors](https://github.com/llvm-mirror/compiler-rt/blob/69445f095c22aac2388f939bedebf224a6efcdaf/lib/asan/asan_interceptors.cpp#L628) [on various functions](https://github.com/llvm-mirror/compiler-rt/blob/69445f095c22aac2388f939bedebf224a6efcdaf/lib/asan/asan_malloc_win.cpp#L492). [Various strategies are tried for putting interceptors](https://github.com/llvm-mirror/compiler-rt/blob/69445f095c22aac2388f939bedebf224a6efcdaf/lib/interception/interception_win.cpp#L826), but they should all fail with ACG enabled. Moreover some of them could potentially take a very long time to do so. Consider for example [this function](https://github.com/llvm-mirror/compiler-rt/blob/69445f095c22aac2388f939bedebf224a6efcdaf/lib/interception/interception_win.cpp#L316), which will iterate over regions of memory looking for a suitable location where asking to allocate RWX memory works, something that will always fail with ACG. This may explain the timeouts, although I don't have confirmed practically that this is the exact reason for those.

After discussing with [:bobowen], we think it should be technically possible to make ASAN working if ACG was enabled by the child process itself dynamically (so after ASAN initialization), and not as part of the startup flags for that process. Although we want ASAN builds to work as close as possible to release builds, it's unclear what we would really gain in doing that.

(In reply to Jeff Muizelaar [:jrmuizel] from comment #9)
> It looks the failure's only happen on Windows ASAN builds. Is there a weird interaction between ASAN and ACG?

Hello, that is very likely indeed. I'm very confident that ACG should be disabled for ASAN to work properly. Below is an explanation why, showing where I would suggest to dig to confirm exactly why that could produce timeouts.

ASAN relies on a open-source run-time library called `clang_rt.asan*.dll` on Windows. This library contains code that [prepares the environment that Firefox will execute in when built with ASAN](https://github.com/llvm-mirror/compiler-rt/blob/69445f095c22aac2388f939bedebf224a6efcdaf/lib/asan/asan_rtl.cpp#L398). As part of this initialization, [it puts interceptors](https://github.com/llvm-mirror/compiler-rt/blob/69445f095c22aac2388f939bedebf224a6efcdaf/lib/asan/asan_interceptors.cpp#L628) [on various functions](https://github.com/llvm-mirror/compiler-rt/blob/69445f095c22aac2388f939bedebf224a6efcdaf/lib/asan/asan_malloc_win.cpp#L492). [Various strategies are tried for putting interceptors](https://github.com/llvm-mirror/compiler-rt/blob/69445f095c22aac2388f939bedebf224a6efcdaf/lib/interception/interception_win.cpp#L826), but they should all fail with ACG enabled. Moreover some of them could potentially take a very long time to do so. Consider for example [this function](https://github.com/llvm-mirror/compiler-rt/blob/69445f095c22aac2388f939bedebf224a6efcdaf/lib/interception/interception_win.cpp#L316), which will iterate over regions of memory looking for a suitable location where asking to allocate RWX memory works, something that will always fail with ACG. This may explain the timeouts, although I don't have confirmed practically that this is the exact reason for those.

After discussing with [:bobowen], we think it should be technically possible to make ASAN working if ACG was enabled by the child process itself dynamically (so after ASAN initialization), and not as part of the startup info for that process. Although we want ASAN builds to work as close as possible to release builds, it's unclear what we would really gain in doing that.

(In reply to Jeff Muizelaar [:jrmuizel] from comment #9)
> It looks the failure's only happen on Windows ASAN builds. Is there a weird interaction between ASAN and ACG?

Hello, that is very likely indeed. I'm very confident that ACG should be disabled for ASAN to work properly. Below is an explanation why, showing where I would suggest to dig to confirm exactly why that could produce timeouts.

ASAN relies on a open-source run-time library called `clang_rt.asan*.dll` on Windows. This library contains code that [prepares the environment that Firefox will execute in when built with ASAN](https://github.com/llvm-mirror/compiler-rt/blob/69445f095c22aac2388f939bedebf224a6efcdaf/lib/asan/asan_rtl.cpp#L398). As part of this initialization, [it puts interceptors](https://github.com/llvm-mirror/compiler-rt/blob/69445f095c22aac2388f939bedebf224a6efcdaf/lib/asan/asan_interceptors.cpp#L628) [on various functions](https://github.com/llvm-mirror/compiler-rt/blob/69445f095c22aac2388f939bedebf224a6efcdaf/lib/asan/asan_malloc_win.cpp#L492). [Various strategies are tried for putting interceptors](https://github.com/llvm-mirror/compiler-rt/blob/69445f095c22aac2388f939bedebf224a6efcdaf/lib/interception/interception_win.cpp#L826), but they should all fail with ACG enabled. Moreover some of them could potentially take a very long time to do so. Consider for example [this function](https://github.com/llvm-mirror/compiler-rt/blob/69445f095c22aac2388f939bedebf224a6efcdaf/lib/interception/interception_win.cpp#L316), which will iterate over regions of memory looking for a suitable location where asking to allocate RWX memory works, something that will always fail with ACG. This may explain the timeouts, although I don't have confirmed practically that this is the exact reason for those.

After discussing with [:bobowen], we think it should be technically possible to make ASAN working if ACG was enabled by the child process itself dynamically (so after ASAN initialization), and not as part of the startup info for that process. Although we want ASAN builds to work as close as possible to release builds, it's unclear what we would really gain by doing that.

(In reply to Jeff Muizelaar [:jrmuizel] from comment #9)
> It looks the failure's only happen on Windows ASAN builds. Is there a weird interaction between ASAN and ACG?

Hello, that is very likely indeed. I'm very confident that ACG should be disabled for ASAN to work properly. Below is an explanation why, showing where I would suggest to dig to confirm exactly why that could produce timeouts.

ASAN relies on a open-source run-time library called `clang_rt.asan*.dll` on Windows. This library contains code that [prepares the environment that Firefox will execute in when built with ASAN](https://github.com/llvm-mirror/compiler-rt/blob/69445f095c22aac2388f939bedebf224a6efcdaf/lib/asan/asan_rtl.cpp#L398). As part of this initialization, [it puts interceptors](https://github.com/llvm-mirror/compiler-rt/blob/69445f095c22aac2388f939bedebf224a6efcdaf/lib/asan/asan_interceptors.cpp#L628) [on various functions](https://github.com/llvm-mirror/compiler-rt/blob/69445f095c22aac2388f939bedebf224a6efcdaf/lib/asan/asan_malloc_win.cpp#L492). [Various strategies are tried for putting interceptors](https://github.com/llvm-mirror/compiler-rt/blob/69445f095c22aac2388f939bedebf224a6efcdaf/lib/interception/interception_win.cpp#L826), but they should all fail with ACG enabled. Moreover some of them could potentially take a very long time to do so. Consider for example [this function](https://github.com/llvm-mirror/compiler-rt/blob/69445f095c22aac2388f939bedebf224a6efcdaf/lib/interception/interception_win.cpp#L316), which will iterate over regions of memory looking for a suitable location where asking to allocate RWX memory works, something that will always fail with ACG. This may explain the timeouts, although I don't have confirmed practically that this is the exact reason for those.

After discussing with [:bobowen], we think it should be technically possible to make ASAN with ACG working if ACG was enabled by the child process itself dynamically (so after ASAN initialization), and not as part of the startup info for that process. Although we want ASAN builds to work as close as possible to release builds, it's unclear what we would really gain by doing that.

(In reply to Jeff Muizelaar [:jrmuizel] from comment #9)
> It looks the failure's only happen on Windows ASAN builds. Is there a weird interaction between ASAN and ACG?

Hello, that is very likely indeed. I'm very confident that ACG should be disabled for ASAN to work properly. Below is an explanation why, showing where I would suggest to dig to confirm exactly why that could produce timeouts.

ASAN relies on a open-source run-time library called `clang_rt.asan*.dll` on Windows. This library contains code that [prepares the environment that Firefox will execute in when built with ASAN](https://github.com/llvm-mirror/compiler-rt/blob/69445f095c22aac2388f939bedebf224a6efcdaf/lib/asan/asan_rtl.cpp#L398). As part of this initialization, [it puts interceptors](https://github.com/llvm-mirror/compiler-rt/blob/69445f095c22aac2388f939bedebf224a6efcdaf/lib/asan/asan_interceptors.cpp#L628) [on various functions](https://github.com/llvm-mirror/compiler-rt/blob/69445f095c22aac2388f939bedebf224a6efcdaf/lib/asan/asan_malloc_win.cpp#L492). [Various strategies are tried for putting interceptors](https://github.com/llvm-mirror/compiler-rt/blob/69445f095c22aac2388f939bedebf224a6efcdaf/lib/interception/interception_win.cpp#L826), but they should all fail with ACG enabled. Moreover some of them could potentially take a very long time to do so. Consider for example [this function](https://github.com/llvm-mirror/compiler-rt/blob/69445f095c22aac2388f939bedebf224a6efcdaf/lib/interception/interception_win.cpp#L316), which will iterate over regions of memory looking for a suitable location where asking to allocate RWX memory works, something that will always fail with ACG. This may explain the timeouts, although I don't have confirmed practically that this is the exact reason for those.

After discussing with [:bobowen], we think it should be technically possible to make ASAN with ACG working if ACG was enabled by the child process itself dynamically (so after ASAN initialization), and not as part of the startup info for that process set by the parent. Although we want ASAN builds to work as close as possible to release builds, it's unclear what we would really gain by doing that.

(In reply to Jeff Muizelaar [:jrmuizel] from comment #9)
> It looks the failure's only happen on Windows ASAN builds. Is there a weird interaction between ASAN and ACG?

Hello, that is very likely indeed. I'm very confident that ACG should be disabled for ASAN to work properly. Below is an explanation why, showing where I would suggest to dig to confirm exactly why that could produce timeouts.

ASAN relies on a open-source run-time library called `clang_rt.asan*.dll` on Windows. This library contains code that [prepares the environment that Firefox will execute in when built with ASAN](https://github.com/llvm-mirror/compiler-rt/blob/69445f095c22aac2388f939bedebf224a6efcdaf/lib/asan/asan_rtl.cpp#L398). As part of this initialization, [it puts interceptors](https://github.com/llvm-mirror/compiler-rt/blob/69445f095c22aac2388f939bedebf224a6efcdaf/lib/asan/asan_interceptors.cpp#L628) [on various functions](https://github.com/llvm-mirror/compiler-rt/blob/69445f095c22aac2388f939bedebf224a6efcdaf/lib/asan/asan_malloc_win.cpp#L492). [Various strategies are tried for putting interceptors](https://github.com/llvm-mirror/compiler-rt/blob/69445f095c22aac2388f939bedebf224a6efcdaf/lib/interception/interception_win.cpp#L826), but they should all fail with ACG enabled. Moreover some of them could potentially take a very long time to fail. Consider for example [this function](https://github.com/llvm-mirror/compiler-rt/blob/69445f095c22aac2388f939bedebf224a6efcdaf/lib/interception/interception_win.cpp#L316), which will iterate over regions of memory looking for a suitable location where asking to allocate RWX memory works, something that will always fail with ACG. This may explain the timeouts, although I don't have confirmed practically that this is the exact reason for those.

After discussing with [:bobowen], we think it should be technically possible to make ASAN with ACG working if ACG was enabled by the child process itself dynamically (so after ASAN initialization), and not as part of the startup info for that process set by the parent. Although we want ASAN builds to work as close as possible to release builds, it's unclear what we would really gain by doing that.

(In reply to Jeff Muizelaar [:jrmuizel] from comment #9)
> It looks the failure's only happen on Windows ASAN builds. Is there a weird interaction between ASAN and ACG?

Hello, that is very likely indeed. I'm very confident that ACG should be disabled for ASAN to work properly. Below is an explanation why, showing where I would suggest to dig to confirm exactly why that could produce timeouts.

ASAN relies on a open-source run-time library called `clang_rt.asan*.dll` on Windows. This library contains code that [prepares the environment that Firefox will execute in when built with ASAN](https://github.com/llvm-mirror/compiler-rt/blob/69445f095c22aac2388f939bedebf224a6efcdaf/lib/asan/asan_rtl.cpp#L398). As part of this initialization, [it puts interceptors](https://github.com/llvm-mirror/compiler-rt/blob/69445f095c22aac2388f939bedebf224a6efcdaf/lib/asan/asan_interceptors.cpp#L628) [on various functions](https://github.com/llvm-mirror/compiler-rt/blob/69445f095c22aac2388f939bedebf224a6efcdaf/lib/asan/asan_malloc_win.cpp#L492). [Various strategies are tried for putting interceptors](https://github.com/llvm-mirror/compiler-rt/blob/69445f095c22aac2388f939bedebf224a6efcdaf/lib/interception/interception_win.cpp#L826), but they should all fail with ACG enabled. Moreover some of them could potentially take a very long time to fail. Consider for example [this function](https://github.com/llvm-mirror/compiler-rt/blob/69445f095c22aac2388f939bedebf224a6efcdaf/lib/interception/interception_win.cpp#L316), which will iterate over regions of memory looking for a suitable location where asking to allocate RWX memory works, something that will always fail with ACG. This may explain the timeouts, although I don't have confirmed practically that this is the exact reason for those.

After discussing with [:bobowen], we think it should be technically possible to make ASAN with ACG working if ACG was enabled by the child process itself dynamically (so after ASAN initialization), and not as part of the startup info for that process set by the parent. Although we want ASAN builds to work as close as possible to release builds, it's unclear what we would really gain by doing that compared to just disabling ACG for ASAN builds.