Bug 81504

Summary: [chromium] DRT crashes at shutdown.
Product: WebKit Reporter: Hao Zheng <zhenghao>
Component: Tools / TestsAssignee: Hao Zheng <zhenghao>
Status: RESOLVED FIXED    
Severity: Normal CC: enne, jamesr, nduca, tkent, tony, webkit.review.bot
Priority: P1    
Version: 528+ (Nightly build)   
Hardware: Unspecified   
OS: Unspecified   
Attachments:
Description Flags
Patch none

Description Hao Zheng 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
Comment 1 Hao Zheng 2012-03-19 07:08:11 PDT
Created attachment 132574 [details]
Patch
Comment 2 Hao Zheng 2012-03-19 07:14:53 PDT
I'm wrong in the first comment. This is not random; it definitely happens after compositing.
Comment 3 Tony Chang 2012-03-19 10:26:00 PDT
This looks sane to me, but I'm not familiar with this code.  Adding people who are.
Comment 4 James Robinson 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?
Comment 5 Tony Chang 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().
Comment 6 James Robinson 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
Comment 7 WebKit Review Bot 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>
Comment 8 WebKit Review Bot 2012-03-19 12:46:28 PDT
All reviewed patches have been landed.  Closing bug.
Comment 9 Hao Zheng 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.