This happens with the following workflow:

1. download is interrupted after browser crash
2. when user restart browser and resumes the download, DownloadItemImpl::ResumeInterruptedDownload() is called, that transitions the current state to RESUMING_INTERNAL and changes is_paused_ to false.
3. DownloadItemImpl::Start() will be called later after several thread hoppings. Because the interrupt reason is DOWNLOAD_INTERRUPT_REASON_NONE, the current state is transitioned to TARGET_PENDING_INTERNAL and it kicks off a task to Initialize the target file
4. And right before that task finishes, DownloadItemImpl::pause() is called. Since the current state is TARGET_PENDING_INTERNAL instead of INTERRUPTED_TARGET_PENDING_INTERNAL, is_paused_ is set to true.
5. the task to initialize the target file is complete, and causes the DCHECK failure.

The main issue here is that in 3, the interrupt reason is DOWNLOAD_INTERRUPT_REASON_NONE rather than CRASH or USER_SHUTDOWN. 
BTW, the DCHECK failure happens only when user resumes a download after a browser crash, and right after user click the resume button the first time. If user resumes a download and pauses it, then start mashing pause/resume, it won't cause any issues.

the problem is also quite racy:

in #2:
if pause() is called before step 3, then the pause() call is ignored.
if pause() is called right after step 3, the the DCHECK failure will happen.

I think we should fix the TODO item in pause(): https://cs.chromium.org/chromium/src/content/browser/download/download_item_impl.cc?q=InterruptAndDiscardPartialState&sq=package:chromium&dr=C&l=361, in that case, calling pause() will always work even if there is no active requst.

The following revision refers to this bug:
  https://chromium.googlesource.com/chromium/src.git/+/c805e12955f1f3b6030f604a6ff5fd3f909a458a

commit c805e12955f1f3b6030f604a6ff5fd3f909a458a
Author: dfalcantara <dfalcantara@chromium.org>
Date: Fri Jan 13 01:02:46 2017

[Download Home] More correctly track paused state

The Download Home frontend shouldn't be directly talking
to the Downloads backend because it's missing information
about the downloads that are stored only on the Java side.
Instead, consult the Java sort-of-backend-but-not-really
shared preferences to know whether or not a download is
actually paused or not.

BUG= 678099 ,651408

Review-Url: https://codereview.chromium.org/2623373002
Cr-Commit-Position: refs/heads/master@{#443423}

[modify] https://crrev.com/c805e12955f1f3b6030f604a6ff5fd3f909a458a/chrome/android/java/src/org/chromium/chrome/browser/download/DownloadManagerService.java
[modify] https://crrev.com/c805e12955f1f3b6030f604a6ff5fd3f909a458a/chrome/android/java/src/org/chromium/chrome/browser/download/DownloadSharedPreferenceHelper.java
[modify] https://crrev.com/c805e12955f1f3b6030f604a6ff5fd3f909a458a/chrome/android/java/src/org/chromium/chrome/browser/download/DownloadUtils.java
[modify] https://crrev.com/c805e12955f1f3b6030f604a6ff5fd3f909a458a/chrome/android/java/src/org/chromium/chrome/browser/download/ui/DownloadHistoryAdapter.java
[modify] https://crrev.com/c805e12955f1f3b6030f604a6ff5fd3f909a458a/chrome/android/java/src/org/chromium/chrome/browser/download/ui/DownloadHistoryItemWrapper.java
[modify] https://crrev.com/c805e12955f1f3b6030f604a6ff5fd3f909a458a/chrome/android/java/src/org/chromium/chrome/browser/download/ui/DownloadItemView.java
[modify] https://crrev.com/c805e12955f1f3b6030f604a6ff5fd3f909a458a/chrome/android/javatests/src/org/chromium/chrome/browser/download/ui/DownloadHistoryAdapterTest.java

Min: Do you think bug would be fixed by the CL in #4?

I think the problem is gone with Dan's CL