Assigning to concern owner from Predator results --
Regression information is not available. The result is the blame information. 

Author: stanisc
Project: chromium
Changelist: https://chromium.googlesource.com/chromium/src/+/acf6801129dff3dba81f6f105713aab173a73e2c
Time: Wed Nov 30 19:56:09 2016
The CL last changed line 157 of file waitable_event_posix.cc, which is stack frame 3. 

Author: mmentovai@google.com
Project: chromium
Changelist: https://chromium.googlesource.com/chromium/src/+/b2e972938cc2a0478c33ff094c6f574f39c41997
Time: Tue Sep 02 18:20:34 2008
The CL last changed line 53 of file message_pump_default.cc, which is stack frame 4. 

Author: gab
Project: chromium
Changelist: https://chromium.googlesource.com/chromium/src/+/27355196d32f75606b3e43b54bd0d03ef42b4579
Time: Thu May 18 06:01:10 2017
The CL last changed line 123 of file run_loop.cc, which is stack frame 5. 

Author: dcheng@chromium.org
Project: chromium
Changelist: https://chromium.googlesource.com/chromium/src/+/92c7f876ef1041d01dc37750420513e19391874c
Time: Fri May 02 18:48:14 2014
The CL last changed line 205 of file render_view_test.cc, which is stack frame 6. 

Author: aizatsky
Project: chromium
Changelist: https://chromium.googlesource.com/chromium/src/+/a5eaabc15d7aa4f4ca4bba17b669435da5c9dab8
Time: Thu Jul 28 00:44:07 2016
The CL last changed line 22 of file renderer_fuzzer.cc, which is stack frame 7.

Suspecting Commit#
https://chromium.googlesource.com/chromium/src/+/27355196d32f75606b3e43b54bd0d03ef42b4579

@gab -- Could you please look into the issue, kindly re-assign if this is not related to your changes.
Thank You.

This has nothing to do with WaitableEvent (no hang is ever directly that class' fault), its users are at fault.

The stack below highlights that the issue is that LLVMFuzzerTestOneInput() hangs in content::RenderViewTest::LoadHTMLWithUrlOverride(), not receiving the quit signal it should.


#3 0x563be5f in base::WaitableEvent::Wait() base/synchronization/waitable_event_posix.cc:157:17
#4 0x5584007 in base::MessagePumpDefault::Run(base::MessagePump::Delegate*) base/message_loop/message_pump_default.cc:53:14
#5 0x55fa523 in base::RunLoop::Run() base/run_loop.cc:123:14
#6 0xde6323b in content::RenderViewTest::LoadHTMLWithUrlOverride(char const*, char const*) content/public/test/render_view_test.cc:205:48
#7 0x50635a in LLVMFuzzerTestOneInput content/test/fuzzer/renderer_fuzzer.cc:22:17
#8 0x528340 in fuzzer::Fuzzer::ExecuteCallback(unsigned char const*, unsigned long) third_party/libFuzzer/src/FuzzerLoop.cpp:463:13
#9 0x5277c6 in fuzzer::Fuzzer::RunOne(unsigned char const*, unsigned long, bool, fuzzer::InputInfo*) third_party/libFuzzer/src/FuzzerLoop.cpp:392:3
#10 0x52b624 in fuzzer::Fuzzer::MutateAndTestOne() third_party/libFuzzer/src/FuzzerLoop.cpp:587:9
#11 0x52ca2e in fuzzer::Fuzzer::Loop(std::__1::vector<std::__1::basic_string<char, std::__1::char_traits<char>, std::__1::allocator<char> >, fuzzer::fuzzer_allocator<std::__1::basic_string<char, std::__1::char_traits<char>, std::__1::allocator<char> > > > const&) third_party/libFuzzer/src/FuzzerLoop.cpp:699:5
#12 0x5106b9 in fuzzer::FuzzerDriver(int*, char***, int (*)(unsigned char const*, unsigned long)) third_party/libFuzzer/src/FuzzerDriver.cpp:738:6
#13 0x53e048 in main third_party/libFuzzer/src/FuzzerMain.cpp:20:10
#14 0x7f45741a0f44 in __libc_start_main /build/eglibc-SvCtMH/eglibc-2.19/csu/libc-start.c:287

Gabriel, thanks a lot for the investigation! Do you know any examples of how it should be handled on caller's side? If yes, may I ask you to point us to such cases? It would be very helpful.

content::RenderViewTest::LoadHTMLWithUrlOverride() 's wait condition needs to be satisfied. I have no idea why it isn't in this case but you can debug into one a test using that that works to see what causes the wait to be satisfied usually.

Automatically applying components based on information from OWNERS files. If this seems incorrect, please apply the Test-Predator-Wrong-Components label.

For more information, please see https://chromium.googlesource.com/chromium/src/+/master/testing/libfuzzer/reference.md.

The link referenced in the description is no longer valid.

We are closing all ooms and timeouts that are unreproducible. We won't be filing such bugs in future.