linux_chromium_asan_rel_ng because of OOM |
|||
Issue descriptionToday the linux_chromium_asan_rel_ng went purple on my CL https://codereview.chromium.org/2271653004/ From the logs [1] it seems like a random test is failing because of OOM. [24750:24760:0824/025427:FATAL:memory.cc(22)] Out of memory. size=4194304 #0 0x000000648301 __interceptor_backtrace #1 0x000007532053 base::debug::StackTrace::StackTrace() #2 0x00000757cc9e logging::LogMessage::~LogMessage() #3 0x0000075fd8af base::(anonymous namespace)::OnNoMemory() #4 0x00000f259581 content::ChildDiscardableSharedMemoryManager::AllocateLockedDiscardableSharedMemory() #5 0x00000f2589ed content::ChildDiscardableSharedMemoryManager::AllocateLockedDiscardableMemory() #6 0x00000bb3fc50 cc::SoftwareImageDecodeController::GetOriginalImageDecode() #7 0x00000bb3d280 cc::SoftwareImageDecodeController::DecodeImageInternal() #8 0x00000bb3bf49 cc::SoftwareImageDecodeController::DecodeImage() #9 0x00000bb4a2cc cc::(anonymous namespace)::ImageDecodeTaskImpl::RunOnWorkerThread() #10 0x000013e4a03b content::CategorizedWorkerPool::RunTaskInCategoryWithLockAcquired() #11 0x000013e47168 content::CategorizedWorkerPool::Run() #12 0x00000767ddbc base::SimpleThread::ThreadMain() #13 0x00000766e713 base::(anonymous namespace)::ThreadFunc() #14 0x7f6f6426ee9a start_thread #15 0x7f6f5f8c036d clone Interestingly, I think I've seen that AllocateLockedDiscardableSharedMemory in a lot of crash reports. So I wonder if something is leaking here in the cc sw decoding path? [1] https://build.chromium.org/p/tryserver.chromium.linux/builders/linux_chromium_asan_rel_ng/builds/214975/steps/browser_tests%20%28with%20patch%29%20on%20Ubuntu-12.04/logs/stdio
,
Aug 24 2016
So the thing that is weird is that it OOM-ed in the context of a test, which I imagine is rather simple. I can imagine if can be WAI if it crashes on the field, as you might be opening a page with lot of kittens while you have 200 tabs. But OOM in a browsertest feels a bit suspicious.
,
Aug 24 2016
Hrmm yeah. I see what you mean. I imagine this warrants investigation (when ever one of us has time to get around to it).
,
Aug 24 2016
It's possible that SW Image path is leaking somewhere. It's also possible that another component is leaking and software images are simply triggering the crash (since they are a large consumer of memory to begin with). It's nice that we have a repro though, I'll take a look.
,
Aug 26 2016
Is this a consistent repro? I ran browser_tests a few times on my machine and no oom crashes yet.
,
Aug 26 2016
primiano: In that stdio output I see a whole swathe of FATAL failures: [18327:18327:0824/024613:FATAL:router.cc(28)] Check failed: !is_valid. The callback passed to ImageDownloader::DownloadImage() was never run. #0 0x000000648301 __interceptor_backtrace #1 0x000007532053 base::debug::StackTrace::StackTrace() #2 0x00000757cc9e logging::LogMessage::~LogMessage() #3 0x00000bdf8353 mojo::internal::(anonymous namespace)::DCheckIfInvalid() #4 0x00000bdf75f8 mojo::internal::(anonymous namespace)::ResponderThunk::DCheckInvalid() #5 0x000003e1ac81 _ZN4base8internal9BindStateIMN7content5mojom46ImageDownloader_DownloadImage_ProxyToResponderEFviRKNSt3__16vectorI8SkBitmapNS5_9allocatorIS7_EEEERKNS6_IN3gfx4SizeENS8_ISE_EEEEEJNS0_13PassedWrapperINS5_10unique_ptrIS4_NS5_14default_deleteIS4_EEEEEEEED2Ev #6 0x000003e1ab06 _ZN4base8internal9BindStateIMN7content5mojom46ImageDownloader_DownloadImage_ProxyToResponderEFviRKNSt3__16vectorI8SkBitmapNS5_9allocatorIS7_EEEERKNS6_IN3gfx4SizeENS8_ISE_EEEEEJNS0_13PassedWrapperINS5_10unique_ptrIS4_NS5_14default_deleteIS4_EEEEEEEE7DestroyEPNS0_13BindStateBaseE #7 0x000013ec2607 _ZN4base8internal9BindStateIMN7content19ImageDownloaderImplEFvjRKNS_8CallbackIFviRKNSt3__16vectorI8SkBitmapNS5_9allocatorIS7_EEEERKNS6_IN3gfx4SizeENS8_ISE_EEEEELNS0_8CopyModeE1EEEPNS2_35MultiResolutionImageResourceFetcherESC_EJNS0_17UnretainedWrapperIS3_EEjSL_EE7DestroyEPNS0_13BindStateBaseE #8 0x0000140cc2c4 content::MultiResolutionImageResourceFetcher::~MultiResolutionImageResourceFetcher() #9 0x000013ec23bd base::STLDeleteElements<>() #10 0x000013b16dd5 content::RenderThreadImpl::Shutdown() #11 0x00000f1a6e1d content::ChildProcess::~ChildProcess() #12 0x000013bb9f9c content::RendererMain() #13 0x0000072c4a2e content::RunZygote() #14 0x0000072c6256 content::RunNamedProcessTypeMain() #15 0x0000072c7ec5 content::ContentMainRunnerImpl::Run() #16 0x0000072c3c3b content::ContentMain() #17 0x000008858a85 content::LaunchTests() #18 0x000007505886 main #19 0x7f574b4057ed __libc_start_main #20 0x000000603541 <unknown> [22865:22865:0824/024743:FATAL:manifest_fetcher.cc(45)] Check failed: !completed_. #0 0x000000648301 __interceptor_backtrace #1 0x000007532053 base::debug::StackTrace::StackTrace() #2 0x00000757cc9e logging::LogMessage::~LogMessage() #3 0x0000140caa3c content::ManifestFetcher::Cancel() #4 0x000013edf691 content::ManifestManager::~ManifestManager() #5 0x000013edffee content::ManifestManager::~ManifestManager() #6 0x000013a78455 content::RenderFrameImpl::~RenderFrameImpl() #7 0x000013a79a3e content::RenderFrameImpl::~RenderFrameImpl() #8 0x000013ab5264 content::RenderFrameImpl::frameDetached() #9 0x00000f979309 blink::FrameLoaderClientImpl::detached() #10 0x0000115d46ea blink::Frame::detach() #11 0x00001169d2a3 blink::LocalFrame::detach() #12 0x000011ade00f blink::Page::willBeDestroyed() #13 0x00000f8ed5cd blink::WebViewImpl::close() #14 0x000013b9342b content::RenderWidget::Close() #15 0x000013b6df82 content::RenderViewImpl::Close() #16 0x00000771a16d base::debug::TaskAnnotator::RunTask() #17 0x00000f6ffc2b blink::scheduler::TaskQueueManager::ProcessTaskFromWorkQueue() #18 0x00000f6fb9fe blink::scheduler::TaskQueueManager::DoWork() #19 0x00000771a16d base::debug::TaskAnnotator::RunTask() #20 0x000007595a35 base::MessageLoop::RunTask() #21 0x000007596636 base::MessageLoop::DeferOrRunPendingTask() #22 0x00000759766f base::MessageLoop::DoWork() #23 0x0000075a029f base::MessagePumpDefault::Run() #24 0x000007594c35 base::MessageLoop::RunHandler() #25 0x00000760d738 base::RunLoop::Run() #26 0x000013bb9f4f content::RendererMain() #27 0x0000072c4a2e content::RunZygote() #28 0x0000072c6256 content::RunNamedProcessTypeMain() #29 0x0000072c7ec5 content::ContentMainRunnerImpl::Run() #30 0x0000072c3c3b content::ContentMain() #31 0x000008858a85 content::LaunchTests() #32 0x000007505886 main #33 0x7f7be26157ed __libc_start_main #34 0x000000603541 <unknown> etc... Should we prioritize looking into this in more detail? |
|||
►
Sign in to add a comment |
|||
Comment 1 by cblume@chromium.org
, Aug 24 2016