New issue
Advanced search Search tips

Issue 762608 link

Starred by 2 users

Issue metadata

Status: Assigned
Owner:
Components:
EstimatedDays: ----
NextAction: ----
OS: ----
Pri: 2
Type: Defect


Previous locations:
monorail:3000


Sign in to add a comment

base::MessageLoop::~MessageLoop() triggering a DCHECK when TLS is clear before termination.

Reported by claudiom...@gmail.com, Aug 24 2017

Issue description

The destructor for base::MessageLoop used to have the following check:

DCHECK(current() == this || !current());

This has since then been changed to:

DCHECK((pump_ && current() == this) || (!pump_ && current() != this));

This check was changed to accommodate for when the loop being bound, due to a thread failing to be created. The problem with this change is that it doesn't account anymore for  !current(), and this is causing problems when a message loop has to be destroyed for the main thread in DLL.

Solution:

Change the check to:

  DCHECK((pump_ && (current() == this || !current())) ||
         (!pump_ && current() != this));


 
You filed this issue with the monorail project, I believe you meant to file against Chromium?  Moving there.
Project: chromium
Moved issue monorail:3000 to now be issue chromium:762608.
Components: Internals>Core
Owner: skyos...@chromium.org
Status: Assigned (was: New)
Sami this is from your change. Thoughts?
Hmm, I'm not sure how the TLS would get cleared before the MessageLoop is destructed. Do you mean the underlying TLS mechanism? Clearing that before the MessageLoop is destructed seems worse since we still run tasks at ML shutdown.
I have seen this happening when having base compiled in a DLL. I only filed an issue because I noticed the check condition had changed in meaning during a refactoring.
Labels: Pri-2
Setting defect without priority to Pri-2.

Sign in to add a comment