Crash ID 313e9b9050000000 corresponds to this.

@1: Yeah, looks like the same as  bug #710131 

<3>[  290.958742] CPU1 PC: <331f9cd4> 0x331f9cd4

I'll try to reproduce / sink my teeth into this tomorrow.  I'm kinda baffled about what could be happening here, but the first thing to do would be to match things up to the address map of whatever process is hanging so we can get some dieassembly.

Wez: the crash you point at says

- 9449.0.0 / 59.0.3065.0

That's different than the version you report above.  Maybe you were on 	9413.0.0 / 59.0.3054.0 before and you got an AU?  I guess you're reproducing the issue on both versions?

Re #3: I started hitting the problem after the auto-update, and it was
tricky to get the device to stay up long enough to show chrome://crashes[1]
- I think I filed the bug from a different device so perhaps I mixed up the
version info. :-/

[1] I did notice that the device stayed up for longer (several minutes) if
I didn't open or close any tabs - so when I Restore'd after a crash after
having opened chrome://crashes, chrome://crashes would be one of the
restored tabs and I could use it and the others for a little while.

Could there be some sort of deadlock on the kernel process table, locking
up a core, or something of that sort?

@5: It's sitting in userspace and the kernel can't cause the core to stop.  The only real explanation here is an errata.

I'm fairly confident that some small change to skia (or the compiler, or the compile flags for skia) is the root cause, but still trying to nail it down exactly.

I'm going to mark this guy a dupe.

Issue 729928 has been merged into this issue.