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

Issue 754421 link

Starred by 2 users

Issue metadata

Status: WontFix
Owner:
Closed: Mar 2018
Cc:
Components:
EstimatedDays: ----
NextAction: ----
OS: Linux
Pri: 3
Type: Bug



Sign in to add a comment

CHECK failure: !g_in_x11_io_error_handler in chrome_browser_main_extra_parts_x11.cc

Project Member Reported by ClusterFuzz, Aug 10 2017

Issue description

Detailed report: https://clusterfuzz.com/testcase?key=5279775743803392

Fuzzer: phoglund_webrtc_peerconnection
Job Type: linux_ubsan_vptr_chrome
Platform Id: linux

Crash Type: CHECK failure
Crash Address: 
Crash State:
  !g_in_x11_io_error_handler in chrome_browser_main_extra_parts_x11.cc
  anonymous namespace)::BrowserX11IOErrorHandler
  _XIOError
  
Sanitizer: undefined (UBSAN)

Reproducer Testcase: https://clusterfuzz.com/download?testcase_id=5279775743803392

Note: This crash might not be reproducible with the provided testcase. That said, for the past 14 days we've been seeing this crash frequently. If you are unable to reproduce this, please try a speculative fix based on the crash stacktrace in the report. The fix can be verified by looking at the crash statistics in the report, a day after the fix is deployed. If the fix resolved the issue, please close the bug by marking as Fixed.

Additional requirements: Requires HTTP

Issue filed automatically.

See https://github.com/google/clusterfuzz-tools for more information.
 
Cc: msrchandra@chromium.org
Labels: Test-Predator-Wrong CF-NeedsTriage
The suspected commit is very old. Redo Task has been performed for regression range.
Adding CF-NeedsTriage label, could some one please look into the issue.
Thank You.

Comment 2 Deleted

Cc: thestig@chromium.org
Components: Internals>Core
Labels: -CF-NeedsTriage
thestig@, can you please see if it's still worth to investigate? since it's an unreproducible CF report.

Thank you in-advance!
Labels: Needs-Feedback
Cc: -thestig@chromium.org
Labels: -Pri-1 -Needs-Feedback Pri-3
Owner: thestig@chromium.org
Status: Assigned (was: Untriaged)
Yes, I'll take the bug and make a blind attempt at fixing it.
From the CF log, BrowserX11IOErrorHandler() is calling itself, which is something we don't want.

[1894:1894:0806/023559.797293:ERROR:x11_util.cc(89)] X IO error received (X server probably went away)
[1539:1539:0806/023559.815270:ERROR:chrome_browser_main_extra_parts_x11.cc(62)] X IO error received (X server probably went away)
[1539:1539:0806/023559.896447:FATAL:chrome_browser_main_extra_parts_x11.cc(59)] Check failed: !g_in_x11_io_error_handler.
#0 0x7fa7d25a2a6d base::debug::StackTrace::StackTrace()
#1 0x7fa7d25d1c49 logging::LogMessage::~LogMessage()
#2 0x7fa7d1e50d90 (anonymous namespace)::BrowserX11IOErrorHandler()
#3 0x7fa7c6d675ee _XIOError
#4 0x7fa7c6d6576a _XReply
#5 0x7fa7c6d5baa5 XQueryPointer
#6 0x7fa7dbcca2a2 views::DesktopScreenX11::GetCursorScreenPoint()
#7 0x7fa7d61c5e15 views::View::IsMouseHovered()
#8 0x7fa7d7fcb0d3 ReloadButton::ChangeMode()
#9 0x7fa7d7c958b1 chrome::BrowserCommandController::UpdateReloadStopState()
#10 0x7fa7d7c80f38 Browser::LoadingStateChanged()
#11 0x7fa7cfabf337 content::WebContentsImpl::LoadingStateChanged()
#12 0x7fa7cfae78fc content::WebContentsImpl::DidStopLoading()
#13 0x7fa7cf214f9f content::FrameTreeNode::DidStopLoading()
#14 0x7fa7cf2d73e1 content::RenderFrameHostImpl::OnDidStopLoading()
#15 0x7fa7cf2dc362 content::RenderFrameHostImpl::RenderProcessGone()
#16 0x7fa7cf9dfc33 content::SiteInstanceImpl::RenderProcessExited()
#17 0x7fa7cf77766c content::RenderProcessHostImpl::ProcessDied()
#18 0x7fa7cf7768d6 content::RenderProcessHostImpl::FastShutdownIfPossible()
#19 0x7fa7d22eb449 browser_shutdown::OnShutdownStarting()
#20 0x7fa7d205e0e3 chrome::SessionEnding()
#21 0x7fa7d1e50e28 (anonymous namespace)::BrowserX11IOErrorHandler()
#22 0x7fa7c6d675ee _XIOError

Cc: thomasanderson@chromium.org e...@chromium.org
Trying to figure out where to break the cycle. Maybe views::DesktopScreenX11::GetCursorScreenPoint()? Is there an easy way to tell the X server connection is dead, so we can avoid calling XQueryPointer()

Comment 8 by kenorb@gmail.com, Oct 9 2017

Related: [Google-chrome crashes on Ubuntu 12.04](https://superuser.com/q/888149/87805)

Comment 9 by e...@chromium.org, Mar 9 2018

Cc: -e...@chromium.org
Un-cc-ing me from all bugs on my final day.
Project Member

Comment 10 by ClusterFuzz, Mar 25 2018

Status: WontFix (was: Assigned)
ClusterFuzz testcase 5279775743803392 is flaky and no longer crashes, so closing issue.

If this is incorrect, please add ClusterFuzz-Wrong label and re-open the issue.

Sign in to add a comment