New issue
Advanced search Search tips

Issue 891481 link

Starred by 1 user

Issue metadata

Status: Assigned
Owner:
Cc:
Components:
EstimatedDays: ----
NextAction: ----
OS: Chrome
Pri: 3
Type: Bug


Participants' hotlists:
Cros-Hwsec-Ready


Sign in to add a comment

chapsd: Crash - Check failed: owning_thread_ref_.is_null

Project Member Reported by emaxx@chromium.org, Oct 2

Issue description

Chrome Version: ToT
OS: Chrome OS

What steps will reproduce the problem?
(1) Start chapsd daemon and quickly after that (less than one second) request to stop it by sending SIGTERM.

What is the expected result?
The daemon shuts down successfully.

What happens instead?
It crashes during shutdown with:
  [lock.cc(19)] Check failed: owning_thread_ref_.is_null().


Supposedly, it crashes during destruction of |chaps::Daemon::lock_| in cases when chaps::InitAsync() is still running by that time. This is possible since nothing on the destruction path of |chaps::Daemon| blocks on waiting until the completion of chaps::InitAsync().
 
Note that while this may crash exactly during the loading of the system token, I don't think it's directly related to bug 844537 since we're not seeing logs about crashes on that bug.

Nonetheless, that issue may still be concerning since this may be another way of how system slot data may become damaged - for instance, in the "system shuts down quickly after boot" scenario (described in bug 844537).
Re comment 1: Thinking more on that, we should NOT assume it's unrelated to bug 844537. Because the logs about the daemon crashing could be just lost since during system shutdown rsyslogd receives SIGTERM (and gets killed) at approximately the same time as chapsd.
Cc: louiscollard@chromium.org
Components: OS>Systems>Security
Labels: Cros-Hwsec-Ready
This seemed to be related to Issue 822489. The fix to that issue might very likely fix this one as well. Will try to verify if this is fixed once I've the CL for that bug ready.
Owner: zuan@chromium.org
Status: Assigned (was: Untriaged)
Provisionally assigning to John to deal with all these "chapsd not waiting for non-main threads on shutdown" issues in one patch ;P

As zuan@ found out, chaps::Daemon::Run() indeed not cares in any way about the threads it started, so those can try to access members of chaps::Daemon after the daemon instance itself has already been destructed.

Sign in to add a comment