Assigning to someone who might know about this, please have a look.

Xing: do you have cycles to look at this?  Reassign back if you don't.

I was looking into this but couldn't find any culprit or person to cc.

The crash is caused by a DCHECK

[FATAL:render_widget_host_view_android.cc(545)] Check failed: locks_on_frame_count_ > 0u (0 vs. 0)

https://build.chromium.org/p/chromium.linux/builders/Android%20Tests%20%28dbg%29/builds/35563

Piece of logcat:

I cr_LibraryLoader: Time to load native libraries: 94 ms (timestamps 8862-8956)
I cr_LibraryLoader: Expected native library version number "54.0.2818.0", actual native library version number "54.0.2818.0"
W chromium: [0803/144425:WARNING:trace_config_file.cc(80)] The trace config file does not exist.
I chromium: [INFO:library_loader_hooks.cc(155)] Chromium logging enabled: level = 0, default verbosity = 0
W chromium: [WARNING:memory_linux.cc(152)] Not feasible.
I cr_Ime  : ImeThread is enabled.
I cr_ChildProcessService: Creating new ChildProcessService pid=23193
I cr_LibraryLoader: Using linker: org.chromium.base.library_loader.LegacyLinker
W View    : requestLayout() improperly called by org.chromium.chrome.browser.compositor.CompositorView{427d2990 V.ED.... ......ID 0,0-1080,1701} during layout: running second layout pass
W View    : requestLayout() improperly called by android.widget.LinearLayout{42a29340 V.E..... ......ID 0,1557-1080,1701 #7f0d02a5 app:id/snackbar} during layout: running second layout pass
I cr_LibraryLoader: Loading chrome
I cr_Ime  : ImeThread is enabled.
D cr_ChildProcLauncher: [ChildProcessLauncher.java:848] on connect callback, pid=23193 context=-2115612496 callbackType=2
I cr_LibraryLoader: Time to load native libraries: 96 ms (timestamps 8979-9075)
I cr_LibraryLoader: Expected native library version number "54.0.2818.0", actual native library version number "54.0.2818.0"
W chromium: [0803/144425:WARNING:trace_config_file.cc(80)] The trace config file does not exist.
I chromium: [INFO:library_loader_hooks.cc(155)] Chromium logging enabled: level = 0, default verbosity = 0
W chromium: [WARNING:memory_linux.cc(152)] Not feasible.
F MessageQueue: IdleHandler threw exception
F MessageQueue: java.lang.VerifyError: org/chromium/content/browser/TracingControllerAndroid
F MessageQueue:  at org.chromium.content.app.ContentApplication.getTracingController(ContentApplication.java:33)
F MessageQueue:  at org.chromium.content.app.ContentApplication$1.queueIdle(ContentApplication.java:50)
F MessageQueue:  at android.os.MessageQueue.next(MessageQueue.java:207)
F MessageQueue:  at android.os.Looper.loop(Looper.java:123)
F MessageQueue:  at android.app.ActivityThread.main(ActivityThread.java:5001)
F MessageQueue:  at java.lang.reflect.Method.invokeNative(Native Method)
F MessageQueue:  at java.lang.reflect.Method.invoke(Method.java:515)
F MessageQueue:  at com.android.internal.os.ZygoteInit$MethodAndArgsCaller.run(ZygoteInit.java:785)
F MessageQueue:  at com.android.internal.os.ZygoteInit.main(ZygoteInit.java:601)
F MessageQueue:  at dalvik.system.NativeStart.main(Native Method)
D cr_tabmodel: [TabPersistentStore.java:861] Serializing tab lists; counts: 1, 0, 0
D cr_tabmodel: [TabPersistentStore.java:861] Serializing tab lists; counts: 2, 0, 0
D cr_tabmodel: [TabPersistentStore.java:861] Serializing tab lists; counts: 3, 0, 0
D cr_tabmodel: [TabPersistentStore.java:861] Serializing tab lists; counts: 4, 0, 0
I cr_Ime  : ImeThread is enabled.
D cr_tabmodel: [TabPersistentStore.java:861] Serializing tab lists; counts: 0, 0, 0
F chromium: [FATAL:render_widget_host_view_android.cc(545)] Check failed: locks_on_frame_count_ > 0u (0 vs. 0)
F chromium:
F libc    : Fatal signal 6 (SIGABRT) at 0x000059f5 (code=-6), thread 23029 (chromium.chrome)

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

commit f0791c79e383a99fe8154e04f82ff3409feb04ff
Author: dgn <dgn@chromium.org>
Date: Wed Aug 03 17:35:24 2016

Disable UndoTabModelTest#testCloseAll

It is hitting DCHECKs on the bots

TBR=peter@chromium.org
BUG= 633607 

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

[modify] https://crrev.com/f0791c79e383a99fe8154e04f82ff3409feb04ff/chrome/android/javatests/src/org/chromium/chrome/browser/tabmodel/UndoTabModelTest.java

Didn't reproduce the bug on local device, but investigate the code a bit. 

Probably the call to break this is line 1879 in render_widget_host_view_android.cc. In CopyFromCompositingSurface it first LockCompositingSurface, then UnLockCompositingSurface later. But ReleaseLocksOnSurface will call UnLockCompositingSurface util locks_on_frame_count_ set to 0, so UnLockCompositingSurface from CopyFromCompositingSurface after ReleaseLocksOnSurface will make it hit the DCHECK.

This looks related to  issue 635730  and  issue 635733  which are also failing on locks_on_fame_count_ > 0u.

I'm thinking (hoping) the root cause for all is the same, rolling all the bugs into one.

 Issue 635733  has been merged into this issue.

 Issue 635730  has been merged into this issue.

taken from the dupes:

https://test-results.appspot.com/dashboards/flakiness_dashboard.html#testType=chrome_public_test_apk&tests=org.chromium.chrome.browser.tabmodel.UndoTabModelTest

#testAddTab and #testSaveSTateCommitesUndo are flaking pretty regularly on tablets. I'm going to restrict them to phones for now.

Example failure attached

Deleted: UndoTabModelTest_Tombstone.txt 98.2 KB

UndoTabModelTest_Tombstone.txt 98.2 KB View Download

The previous example was for #testSaveStateCommitsUndo.

This new example is for #testAddTab. The final error is the same, but the stacktrace leading up to it is a bit different.

Deleted: UndoTabModelTest_Tombstone_AddTab.txt 99.0 KB

UndoTabModelTest_Tombstone_AddTab.txt 99.0 KB View Download

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

commit 55094d61a32a7cae3c758ba4daf60557acfe7dee
Author: twellington <twellington@chromium.org>
Date: Thu Aug 11 18:45:05 2016

Restrict UndoTabModelTest#testAddTab and #testSaveStateCommitsUndo to phones

These tests flak regularly on tablets.

BUG= 633607 
TBR=dfalcantara@chromium.org

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

[modify] https://crrev.com/55094d61a32a7cae3c758ba4daf60557acfe7dee/chrome/android/javatests/src/org/chromium/chrome/browser/tabmodel/UndoTabModelTest.java

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

commit 55094d61a32a7cae3c758ba4daf60557acfe7dee
Author: twellington <twellington@chromium.org>
Date: Thu Aug 11 18:45:05 2016

Restrict UndoTabModelTest#testAddTab and #testSaveStateCommitsUndo to phones

These tests flak regularly on tablets.

BUG= 633607 
TBR=dfalcantara@chromium.org

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

[modify] https://crrev.com/55094d61a32a7cae3c758ba4daf60557acfe7dee/chrome/android/javatests/src/org/chromium/chrome/browser/tabmodel/UndoTabModelTest.java

K and L tablets are flaky on testReverseOrderRestore too, so I'll put together a CL to restrict it too.  https://test-results.appspot.com/dashboards/flakiness_dashboard.html#tests=org.chromium.chrome.browser.tabmodel.UndoTabModelTest%23testReverseOrderRestore&testType=chrome_public_test_apk

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

commit 32984105b1059344cf886caf639dc55a530456ae
Author: donnd <donnd@chromium.org>
Date: Fri Aug 19 18:47:55 2016

Restrict UndoTabModelTest#testReverseOrderRestore to phone.

This test is flaking on tablets, especially KitKat.

BUG= 633607 

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

[modify] https://crrev.com/32984105b1059344cf886caf639dc55a530456ae/chrome/android/javatests/src/org/chromium/chrome/browser/tabmodel/UndoTabModelTest.java

Issue 674654 has been merged into this issue.

Merged disabled #testUndoNotSupported into this bug.

Never mind -- the #testUndoNotSupported was due to a different issue.

You started fixing this bug over two years ago. Are you still working on it? You can update the status to "archived", "wontfix", or "closed". You can remove yourself as owner and change status to "untriaged", but if this is still a real bug, please do not sit on it.

No longer flaky on the configurations that are enabled.