New issue
Advanced search Search tips
Note: Color blocks (like █ or █) mean that a user may not be available. Tooltip shows the reason.

Issue 776357 link

Starred by 1 user
Status: Available
Owner: ----
Cc:
omrilio@chromium.org
█ blakeo@chromium.org
yhanada@chromium.org
pcovell@chromium.org
█ dvallet@chromium.org
Components:
EstimatedDays: ----
NextAction: ----
OS: ----
Pri: 3
Type: Bug


Participants' hotlists:
Fixing-touch


Sign in to add a comment

KeyboardTestSuite Initialize() does not always run

Project Member Reported by blakeo@chromium.org, Oct 19 2017 
KeyboardControllerTest.VisibilityChangeWithTextInputTypeChange always crashes on the first attempt when run locally. Then it mysteriously passes on the first retry attempt.

Stack trace:

...

[ RUN      ] KeyboardControllerTest.VisibilityChangeWithTextInputTypeChange
[102135:102135:1019/233241.967906:7462990042609:ERROR:input_controller.cc(104)] Not implemented reached in virtual void ui::(anonymous namespace)::StubInputController::SetTouchEventLoggingEnabled(bool)
[102135:102135:1019/233241.968195:7462990042894:ERROR:input_controller.cc(104)] Not implemented reached in virtual void ui::(anonymous namespace)::StubInputController::SetTouchEventLoggingEnabled(bool)
Received signal 11 SEGV_MAPERR 000000000000
#0 0x7f9a44a98d7d base::debug::StackTrace::StackTrace()
#1 0x7f9a44a972fc base::debug::StackTrace::StackTrace()
#2 0x7f9a44a98777 base::debug::(anonymous namespace)::StackDumpSignalHandler()
#3 0x7f9a44ec9330 <unknown>
#4 0x7f9a41fe11b0 gl::init::HasGLOzone()
#5 0x7f9a41fe0f40 gl::init::HasGLOzone()
#6 0x7f9a41fe0b4a gl::init::CreateOffscreenGLSurfaceWithFormat()
#7 0x7f9a41fdc27c gl::init::CreateOffscreenGLSurface()
#8 0x7f9a425ca24a gpu::InProcessCommandBuffer::InitializeOnGpuThread()
#9 0x7f9a425d2dfd _ZN4base8internal13FunctorTraitsIMN3gpu22InProcessCommandBufferEFbRKNS3_27InitializeOnGpuThreadParamsEEvE6InvokeIPS3_JS6_EEEbS8_OT_DpOT0_
#10 0x7f9a425d2d2f _ZN4base8internal12InvokeHelperILb0EbE8MakeItSoIRKMN3gpu22InProcessCommandBufferEFbRKNS5_27InitializeOnGpuThreadParamsEEJPS5_S8_EEEbOT_DpOT0_
#11 0x7f9a425d2cbd _ZN4base8internal7InvokerINS0_9BindStateIMN3gpu22InProcessCommandBufferEFbRKNS4_27InitializeOnGpuThreadParamsEEJNS0_17UnretainedWrapperIS4_EES5_EEEFbvEE7RunImplIRKS9_RKNSt3__15tupleIJSB_S5_EEEJLm0ELm1EEEEbOT_OT0_NSI_16integer_sequenceImJXspT1_EEEE
#12 0x7f9a425d2bcc _ZN4base8internal7InvokerINS0_9BindStateIMN3gpu22InProcessCommandBufferEFbRKNS4_27InitializeOnGpuThreadParamsEEJNS0_17UnretainedWrapperIS4_EES5_EEEFbvEE3RunEPNS0_13BindStateBaseE
#13 0x7f9a425d368d _ZNKR4base17RepeatingCallbackIFbvEE3RunEv
#14 0x7f9a425cb665 gpu::(anonymous namespace)::RunTaskWithResult<>()
#15 0x7f9a425d3300 _ZN4base8internal13FunctorTraitsIPFvNS_17RepeatingCallbackIFbvEEEPbPNS_13WaitableEventEEvE6InvokeIJRKS4_RKS5_RKS7_EEEvS9_DpOT_
#16 0x7f9a425d3290 _ZN4base8internal12InvokeHelperILb0EvE8MakeItSoIRKPFvNS_17RepeatingCallbackIFbvEEEPbPNS_13WaitableEventEEJRKS6_RKS7_RKS9_EEEvOT_DpOT0_
#17 0x7f9a425d322d _ZN4base8internal7InvokerINS0_9BindStateIPFvNS_17RepeatingCallbackIFbvEEEPbPNS_13WaitableEventEEJS5_S6_S8_EEEFvvEE7RunImplIRKSA_RKNSt3__15tupleIJS5_S6_S8_EEEJLm0ELm1ELm2EEEEvOT_OT0_NSH_16integer_sequenceImJXspT1_EEEE
#18 0x7f9a425d30fc _ZN4base8internal7InvokerINS0_9BindStateIPFvNS_17RepeatingCallbackIFbvEEEPbPNS_13WaitableEventEEJS5_S6_S8_EEEFvvEE3RunEPNS0_13BindStateBaseE
#19 0x7f9a44a46d01 _ZNO4base12OnceCallbackIFvvEE3RunEv
#20 0x7f9a44a9d6c0 base::debug::TaskAnnotator::RunTask()
#21 0x7f9a44b3bca3 base::internal::IncomingTaskQueue::RunTask()
#22 0x7f9a44b43e16 base::MessageLoop::RunTask()
#23 0x7f9a44b44083 base::MessageLoop::DeferOrRunPendingTask()
#24 0x7f9a44b44381 base::MessageLoop::DoWork()
#25 0x7f9a44b486a8 base::MessagePumpDefault::Run()
#26 0x7f9a44b436e6 base::MessageLoop::Run()
#27 0x7f9a44bf1cff base::RunLoop::Run()
#28 0x7f9a44cb6442 base::Thread::Run()
#29 0x7f9a44cb6ff9 base::Thread::ThreadMain()
#30 0x7f9a44c9c7d1 base::(anonymous namespace)::ThreadFunc()
#31 0x7f9a44ec1184 start_thread
#32 0x7f9a37ce8ffd clone
  r8: 0000000000000000  r9: 00007f9a2b3815e0 r10: 0000000000000020 r11: 00007f9a37d75110
 r12: 0000000000000000 r13: 0000000000000000 r14: 00007f9a2b3859c0 r15: 00007f9a2b385700
  di: 0000118cf1bf5958  si: 0000000000000000  bp: 00007f9a2b381aa0  bx: 0000000000000000
  dx: 00007f9a2b381d68  ax: 0000000000000000  cx: 00007f9a406d5060  sp: 00007f9a2b381a90
  ip: 00007f9a41fe11b0 efl: 0000000000010202 cgf: 0000000000000033 erf: 0000000000000004
 trp: 000000000000000e msk: 0000000000000000 cr2: 0000000000000000
[end of stack trace]

...

Retrying 1 test (retry #1)
[22/22] KeyboardControllerTest.VisibilityChangeWithTextInputTypeChange (215 ms)
SUCCESS: all tests passed.

Comment 1 by blakeo@chromium.org, Oct 19 2017

Components: UI>Input>VirtualKeyboard

Comment 2 by blakeo@chromium.org, Oct 20 2017

Summary: KeyboardTestSuite Initialize() does not always run (was: KeyboardControllerTest.VisibilityChangeWithTextInputTypeChange always crashes on the first attempt)
It seems this is a little more localized to the keyboard tests than specifically a problem with the Ozone OpenGL stuff as I originally thought. Placing a log statement in the KeyboardTestSuite::Initialize() in https://cs.chromium.org/chromium/src/ui/keyboard/test/run_all_unittests.cc will not always get run before the test, and those tests that use RunLoop will crash the first time they run. If the log statement runs, those tests don't crash. 

Changing title of this bug to something more specific.
Project Member

Comment 3 by bugdroid1@chromium.org, Oct 20 2017 

The following revision refers to this bug:
  https://chromium.googlesource.com/chromium/src.git/+/dc47eafa93b460dc8112be308a241a55d955862d

commit dc47eafa93b460dc8112be308a241a55d955862d
Author: Blake O'Hare <blakeo@chromium.org>
Date: Fri Oct 20 12:10:36 2017

Ensure Ozone initialized when using RunLoop

OzonePlatformX11::GetSurfaceFactoryOzone() is returning a nullptr
sometimes on the first time it is called. This function is inlined into
the gl::init::HasGLOzone() so the stack trace listed in the bug is a
little deceptive.

InitializeForGPU seems to be safe as it No-ops if it is redundantly
invoked.

It seems that the initializer for KeyboardTestSuite (which is where our
call to initialize test open GL stuff) is not running (according to log
output or lack thereof) but only some of the time. If a test runs by
itself, it gets run. If it gets run with a wide filter, then it does
not for the first few tests.

I've updated the bug to investigate this further, but for now, prevent
this crash from occurring.

Bug: 776357
Change-Id: I535c1813e13228a61f22d73018e9eac4880f88c1
Reviewed-on: https://chromium-review.googlesource.com/727791
Commit-Queue: Blake O'Hare <blakeo@chromium.org>
Reviewed-by: Yuichiro Hanada <yhanada@chromium.org>
Cr-Commit-Position: refs/heads/master@{#510408}
[modify] https://crrev.com/dc47eafa93b460dc8112be308a241a55d955862d/ui/keyboard/BUILD.gn
[modify] https://crrev.com/dc47eafa93b460dc8112be308a241a55d955862d/ui/keyboard/keyboard_controller_unittest.cc

Comment 4 by shend@chromium.org, Jul 4 

Hi Blake, is this fixed?

Comment 5 by shend@chromium.org, Sep 10

Owner: ----
Status: Available (was: Assigned)
blakeo@ is no longer working on virtual keyboard. Marking as available.

Comment 6 by ligimole@google.com, Nov 19

Labels: Hotlist-DesktopUIToolingRequired Hotlist-DesktopUIChecked
***UI Mass Triage ****
►

Sign in to add a comment