OriginPolicyThrottleTests/OriginPolicyThrottleTest.RunRequestEndToEnd/1 fails if OutOfBlinkCORS is enabled |
|
Issue description
I'm trying to enable OutOfBlinkCORS by default, but this test fails.
In this test, actual network requests should not be made.
With current setting, it does not happen, but once OutOfBlinkCORS is enabled, it does probably just due to timing changes.
I took a look, and noticed it correctly uses TestNavigationURLLoader for testing, but I could not figure out how I can solve this problem.
./out/Release/content_unittests --disable-features=NetworkService --enable-features=OutOfBlinkCORS --gtest_filter=OriginPolicyThrottleTests/OriginPolicyThrottleTest.RunRequestEndToEnd/1
IMPORTANT DEBUGGING NOTE: batches of tests are run inside their
own process. For debugging a test inside a debugger, use the
--gtest_filter=<your_test_name> flag along with
--single-process-tests.
Using sharding settings from environment. This is shard 0/1
Using 1 parallel jobs.
Note: Google Test filter = OriginPolicyThrottleTests/OriginPolicyThrottleTest.RunRequestEndToEnd/1
[==========] Running 1 test from 1 test case.
[----------] Global test environment set-up.
[----------] 1 test from OriginPolicyThrottleTests/OriginPolicyThrottleTest
[ RUN ] OriginPolicyThrottleTests/OriginPolicyThrottleTest.RunRequestEndToEnd/1
[52857:52857:1108/165513.105842:695586594438:FATAL:message_loop_current.cc(219)] Check failed: MessageLoop::TYPE_IO == loop->type() (3 vs. 1)
#0 0x7f5b5bf2cc1f base::debug::StackTrace::StackTrace()
#1 0x7f5b5be541ab logging::LogMessage::~LogMessage()
#2 0x7f5b5be60c75 base::MessageLoopCurrentForIO::Get()
#3 0x7f5b5bb3e6e0 net::SocketPosix::Connect()
#4 0x7f5b5bb41609 net::TCPSocketPosix::Connect()
#5 0x7f5b5b9d2449 net::TCPClientSocket::DoConnect()
#6 0x7f5b5b9d1de7 net::TCPClientSocket::DoConnectLoop()
#7 0x7f5b5b9d1c84 net::TCPClientSocket::Connect()
#8 0x7f5b5b9d4ee7 net::TransportConnectJob::DoTransportConnect()
#9 0x7f5b5b9d47a6 net::TransportConnectJob::DoLoop()
#10 0x7f5b5b9d460e net::TransportConnectJob::OnIOComplete()
#11 0x560a10ce99a2 net::MockHostResolverBase::LegacyRequestImpl::LegacyApiCallback()
#12 0x560a10ce89a6 net::MockHostResolverBase::RequestImpl::OnAsyncCompleted()
#13 0x560a10ce7836 net::MockHostResolverBase::ResolveNow()
#14 0x560a10cea2a8 _ZN4base8internal7InvokerINS0_9BindStateIMN3net20MockHostResolverBaseEFvmEJNS_7WeakPtrIS4_EEmEEEFvvEE7RunOnceEPNS0_13BindStateBaseE
#15 0x7f5b5be34c12 base::debug::TaskAnnotator::RunTask()
#16 0x7f5b5be634bf base::MessageLoop::RunTask()
#17 0x7f5b5be63952 base::MessageLoop::DoWork()
#18 0x7f5b5be66089 base::MessagePumpGlib::Run()
#19 0x7f5b5be62f91 base::MessageLoop::Run()
#20 0x7f5b5be96476 base::RunLoop::Run()
#21 0x7f5b5be96b77 base::RunLoop::RunUntilIdle()
#22 0x560a10d20691 content::RenderViewHostTestHarness::TearDown()
#23 0x560a10c455a0 testing::TestInfo::Run()
#24 0x560a10c45ab7 testing::TestCase::Run()
#25 0x560a10c51e17 testing::internal::UnitTestImpl::RunAllTests()
#26 0x560a10c5198d testing::UnitTest::Run()
#27 0x560a10d58ef1 base::TestSuite::Run()
#28 0x560a10d60fdd base::(anonymous namespace)::LaunchUnitTestsInternal()
#29 0x560a10d60e31 base::LaunchUnitTests()
#30 0x560a10ceeae6 main
#31 0x7f5b507242b1 __libc_start_main
#32 0x560a0f93c02a _start
[52850:52853:1108/165513.243431:695586732347:ERROR:kill_posix.cc(84)] Unable to terminate process group 52857: No such process (3)
[1/1] OriginPolicyThrottleTests/OriginPolicyThrottleTest.RunRequestEndToEnd/1 (CRASHED)
1 test crashed:
OriginPolicyThrottleTests/OriginPolicyThrottleTest.RunRequestEndToEnd/1 (../../content/browser/frame_host/origin_policy_throttle_unittest.cc:74)
,
Nov 8
Looking... I can reproduce, but am not quite sure what to make of this. The assertion triggers in code far away from mine, and seems to complain that it expects to be run on the IO message loop, but is really run on the default message loop. My best guess is: I've seen an issue like that before, where the test setup code needed some magic incantation to set up the appropriate scheduler thingies, so that the test code would even have the required loop/scheduler setup. (Which apparently isn't done by default, since most tests won't care.) I'll look around a bit to see if I can find anything...
,
Nov 8
At this point, I'm unfortunately fairly confused. My understanding so far: The test runs through, and during TearDown() the test harness runs RunUntilIdle(), during which it runs code that apparently expects to be run on the network thread. - My code-under-test starts a network request via SimpleURLLoader. It attempts to cancel it (& free all associated resources) by releasing the SimpleURLLoader instance. - Since RunUntilIdle is still trying to run network-related tasks, I assume that the cancellation didn't cancel all sub-tasks of the request. - I tried various ways of forcing a flush of the run queue, or setting up the test thread bundle differently (which manages the queues in the test harness), but with no success. I think we need to get help from someone that understands the interactions between SimpleURLLoader and threading infrastructure better.
,
Nov 9
I think a right fix is to use TestURLLoaderFactory in unit tests. For instance following my change fixed similar issue on SearchProviderTest. https://chromium-review.googlesource.com/c/chromium/src/+/1226672/ This test had an interface to use it from the beginning, but just one test didn't use it mistakenly. So the fix was easy. I think if TestNavigationURLLoader could use TestURLLoaderFactory for testing, but I haven't understood call chains around this test yet. |
|
►
Sign in to add a comment |
|
Comment 1 by toyoshim@google.com
, Nov 8Labels: OOR-CORS