Ah, this one is a bit sneaky.

TimeTicks is a uint64_t.

The test tries to set an alarm for 10s ago. Because the Fuchsia tests are run in a freshly created VM, when it tries to do

  ArmAtStartTime(TimeTicks::Now() - time_delta);

where time_delta is 10s, if the VM hasn't been running for very long, then TimeTicks::Now() < time_delta, resulting in a very large wait time.

Oh, actually TimeTicks is int64_t, even though mx_time_t is uint64_t.

But, when the watchdog time gets armed for approximately -9s (i.e. start_time_ of -9s here https://cs.chromium.org/chromium/src/base/threading/watchdog.cc?rcl=1a947b509b80615967ccdc266ba06ffd7eaf4dbe&l=98

then in the main wakeup thread https://cs.chromium.org/chromium/src/base/threading/watchdog.cc?rcl=1a947b509b80615967ccdc266ba06ffd7eaf4dbe&l=134 it thinks it's really late so the hung-in-a-debugger path kicks in

  static_data->last_debugged_alarm_time > watchdog_->start_time_

and the alarm is disarmed and ignored, rather than triggered and disarmed. I think the correct fix is probably to initialize last_debugged_alarm_time to int64_t::min, rather than 0.

+miu might be interested in this behaviour.

Fixed by https://chromium-review.googlesource.com/c/539058/ when bugdroid was on vacation.