RESOLVED FIXED Bug 81504
[chromium] DRT crashes at shutdown.
https://bugs.webkit.org/show_bug.cgi?id=81504
Summary [chromium] DRT crashes at shutdown.
Hao Zheng
Reported 2012-03-19 02:43:34 PDT
In debug build of DRT, it crashes randomly at shutdown. I think it's due to a race condition. I can trigger the crash easily by this test: out/Debug/DumpRenderTree /usr/local/code/webkit.git/LayoutTests/compositing/iframes/overlapped-nested-iframes.html The stacktrace: ASSERTION FAILED: !CCLayerTreeHost::anyLayerTreeHostInstanceExists() Source/WebKit/chromium/src/WebCompositorImpl.cpp(78) : static void WebKit::WebCompositorImpl::shutdown() 1 0x48fd50 2 0x48fbbf 3 0x46cc36 4 0x4378d3 5 0x7fb676dcac4d __libc_start_main 6 0x422fd9 [30647:30647:19876206991:ERROR:process_util_posix.cc(142)] Received signal 11 base::debug::StackTrace::StackTrace() [0x7315c6] base::(anonymous namespace)::StackDumpSignalHandler() [0x6ec18d] 0x7fb676ddfaf0 WebKit::WebCompositorImpl::shutdown() [0x48fd5a] WebKit::WebCompositor::shutdown() [0x48fbbf] TestShell::~TestShell() [0x46cc36] main [0x4378d3] 0x7fb676dcac4d 0x422fd9
Attachments
Patch (2.28 KB, patch)
2012-03-19 07:08 PDT, Hao Zheng
no flags
Hao Zheng
Comment 1 2012-03-19 07:08:11 PDT
Hao Zheng
Comment 2 2012-03-19 07:14:53 PDT
I'm wrong in the first comment. This is not random; it definitely happens after compositing.
Tony Chang
Comment 3 2012-03-19 10:26:00 PDT
This looks sane to me, but I'm not familiar with this code. Adding people who are.
James Robinson
Comment 4 2012-03-19 11:12:36 PDT
I think we have to shut down WebKit::WebCompositor before we stop threading - when does that happen in DRT?
Tony Chang
Comment 5 2012-03-19 11:44:09 PDT
(In reply to comment #4) > I think we have to shut down WebKit::WebCompositor before we stop threading - when does that happen in DRT? When exiting main(), we ~WebKitSupportTestEnvironment gets run, which calls webkit_support::TearDownTestEnvironment(), which calls WebKit::shutdown(). I believe that's when threading is stopped. So, it's still after the new location of WebCompositor::shutdown().
James Robinson
Comment 6 2012-03-19 12:29:36 PDT
Comment on attachment 132574 [details] Patch OK, that should be fine then! We definitely should be shutting down after all WebViews are gone
WebKit Review Bot
Comment 7 2012-03-19 12:46:23 PDT
Comment on attachment 132574 [details] Patch Clearing flags on attachment: 132574 Committed r111220: <http://trac.webkit.org/changeset/111220>
WebKit Review Bot
Comment 8 2012-03-19 12:46:28 PDT
All reviewed patches have been landed. Closing bug.
Hao Zheng
Comment 9 2012-03-19 22:43:15 PDT
(In reply to comment #5) > (In reply to comment #4) > > I think we have to shut down WebKit::WebCompositor before we stop threading - when does that happen in DRT? > > When exiting main(), we ~WebKitSupportTestEnvironment gets run, which calls webkit_support::TearDownTestEnvironment(), which calls WebKit::shutdown(). I believe that's when threading is stopped. So, it's still after the new location of WebCompositor::shutdown(). Thanks for your explanation, Tony. I found it kind of tricky to load a blank page in ~WebViewHost, which is called by ~TestShell. Howerver, loading a page results in some function calls eventually going back into TestShell again, which is at the state of destruction then. This is kind of dangerous to me.
Note You need to log in before you can comment on or make changes to this bug.