FATAL while dooming entry |
|||||
Issue descriptionon ToT in debug mode on linux (while playing media) [23106:23139:0711/144611.132716:FATAL:http_cache.cc(617)] Check failed: entry_ptr->writer || !entry_ptr->readers.empty() || entry_ptr->headers_transaction || entry_ptr->will_process_queued_transactions. #0 0x7f466b6047ed base::debug::StackTrace::StackTrace() #1 0x7f466b602e2c base::debug::StackTrace::StackTrace() #2 0x7f466b692faa logging::LogMessage::~LogMessage() #3 0x7f4668e4e7c7 net::HttpCache::DoomEntry() #4 0x7f4668e724f3 net::HttpCache::Transaction::DoDoomEntry() #5 0x7f4668e6a99d net::HttpCache::Transaction::DoLoop() #6 0x7f4668e6c34a net::HttpCache::Transaction::Start() #7 0x7f46694707e7 net::URLRequestHttpJob::StartTransactionInternal() #8 0x7f466946ff2c net::URLRequestHttpJob::MaybeStartTransactionInternal() #9 0x7f466946fcf9 net::URLRequestHttpJob::StartTransaction() #10 0x7f466947131d net::URLRequestHttpJob::SetCookieHeaderAndStart() #11 0x7f4668dde15f _ZN4base8internal13FunctorTraitsIMN3net14MDnsClientImpl4CoreEFvRKNSt3__14pairINS5_12basic_stringIcNS5_11char_traitsIcEENS5_9allocatorIcEEEEtEEEvE6InvokeIRKNS_7WeakPtrIS4_EEJSF_EEEvSH_OT_DpOT0_ #12 0x7f4669357e85 _ZN4base8internal12InvokeHelperILb1EvE8MakeItSoIRKMN3net11SpdySessionEFvRKNS_7WeakPtrINS4_17SpdyStreamRequestEEEERKNS6_IS5_EEJSA_EEEvOT_OT0_DpOT1_ #13 0x7f466947a8e0 _ZN4base8internal7InvokerINS0_9BindStateIMN3net17URLRequestHttpJobEFvRKNSt3__16vectorINS3_15CanonicalCookieENS5_9allocatorIS7_EEEEEJNS_7WeakPtrIS4_EEEEEFvSC_EE7RunImplIRKSE_RKNS5_5tupleIJSG_EEEJLm0EEEEvOT_OT0_NS_13IndexSequenceIJXspT1_EEEESC_ #14 0x7f466947a824 _ZN4base8internal7InvokerINS0_9BindStateIMN3net17URLRequestHttpJobEFvRKNSt3__16vectorINS3_15CanonicalCookieENS5_9allocatorIS7_EEEEEJNS_7WeakPtrIS4_EEEEEFvSC_EE3RunEPNS0_13BindStateBaseESC_ #15 0x7f4668b08181 _ZNO4base8CallbackIFvRKN3net10FileStream7Context8IOResultEELNS_8internal8CopyModeE0ELNS8_10RepeatModeE0EE3RunES6_ #16 0x7f4668c037ae net::CookieMonster::GetCookieListWithOptionsTask::Run() #17 0x7f4668c0a35e net::CookieMonster::DoCookieTaskForURL() #18 0x7f4668c0b076 net::CookieMonster::GetCookieListWithOptionsAsync() #19 0x7f466946d69a net::URLRequestHttpJob::AddCookieHeaderAndStart() #20 0x7f466946c75d net::URLRequestHttpJob::Start() #21 0x7f46694422d2 net::URLRequest::StartJob() #22 0x7f4669441737 net::URLRequest::BeforeRequestComplete() #23 0x7f4669440ebc net::URLRequest::Start() #24 0x7f46653626b8 content::ResourceLoader::StartRequestInternal() #25 0x7f4665361fbf content::ResourceLoader::Resume() #26 0x7f46653645f5 content::ResourceLoader::ScopedDeferral::~ScopedDeferral() #27 0x7f466535c2e1 content::ResourceLoader::StartRequest() #28 0x7f4665340ea3 content::ResourceDispatcherHostImpl::StartLoading()
,
Jul 12 2017
,
Jul 13 2017
I hit this bug again today, here is what I did: (Not sure how reproducable this is) I built a tip-of-tree chrome with debug and proprietary_codecs (gn.args follow) ==========gn.args=========== # Build arguments go here. Examples: is_component_build = true is_debug = true use_goma = true #goma_dir = "~/lib/goma" proprietary_codecs=true ffmpeg_branding="Chrome" media_use_ffmpeg=true # See "gn args <dir_name> --list" for available build arguments. ====================== I downloaded this html file: https://bugs.chromium.org/p/chromium/issues/attachment?aid=292530 Then loaded that file in the browser and reloaded a few times. I also had some command line arguments that may affect timing: -vmodule=*webmediaplayer*=2 -vmodule=*ultibuffer*=2
,
Jul 14 2017
It seems to be fairly repeatable, and is affecting my ability to diagnose other bugs, upping the priority.
,
Jul 14 2017
Not able to reproduce with the given steps. It might be related to the fix in https://codereview.chromium.org/2970133002/ Could you please apply the latest patch in that CL to tip-of-tree chrome and see if the crash goes away? Thanks!
,
Jul 14 2017
The patch didn't seem to help. Everything seemed fine until I did did a shift-reload (hold shift and press the reload button) though. Maybe that's what I did when it happened last time too, I don't actually remember.
,
Jul 14 2017
The CL https://codereview.chromium.org/2970133002/ will be committed in a few hours once the bots complete.
,
Jul 14 2017
Did a some more testing, and I haven't been able to nail down exactly what causes the crash. It seems that just hitting reload is not enough. Just hitting shift-reload is not enough, but if I do a regular reload, and then a shift-reload afterwards, it has a pretty good chance of crashing.
,
Jul 14 2017
I am able to now reproduce this with a combination of lot of reloads and shift reloads. Looking into the cause.
,
Jul 17 2017
Found the root cause code path where the entry_ptr might be becoming empty but not getting destroyed. (https://cs.chromium.org/chromium/src/net/http/http_cache.cc?sq=package:chromium&l=918) Working on a CL to fix this.
,
Jul 17 2017
,
Jul 17 2017
The following revision refers to this bug: https://chromium.googlesource.com/chromium/src.git/+/6b8278e157eccfb90342a80469231141374667f5 commit 6b8278e157eccfb90342a80469231141374667f5 Author: Shivani Sharma <shivanisha@chromium.org> Date: Mon Jul 17 22:12:23 2017 Empty entry to be destroyed in DoneWithEntry Bug: 741116 Change-Id: I58cbe1714808fa9a36a322ff26e65b93259e288d Reviewed-on: https://chromium-review.googlesource.com/574874 Commit-Queue: Shivani Sharma <shivanisha@chromium.org> Reviewed-by: Josh Karlin <jkarlin@chromium.org> Cr-Commit-Position: refs/heads/master@{#487268} [modify] https://crrev.com/6b8278e157eccfb90342a80469231141374667f5/net/http/http_cache.cc
,
Jul 17 2017
|
|||||
►
Sign in to add a comment |
|||||
Comment 1 by shivanisha@chromium.org
, Jul 12 2017