I am seeing what looks like similar behavior on 55 Monroe, an LG Chromebase all-in-one 22CV241:
Version 55.0.2883.105 (64-bit)
Platform 8872.76.0 (Official Build) stable-channel monroe
Firmware Google_Monroe.4921.17.0
My gut sense is a resources issue. Many tabs open, JavaScript intensive sites, memory intensive too. Hangs for a couple minutes, then blacks out and comes back up, offering option to restore tabs. My apologies for the +1, but this is a production release OS on which I am seeing this behavior. Unit has limited RAM, may simply be a resource allocation issue. This isn't Issue 661656 or  Issue 652110  perhaps?

danakj: Can you help triage this? Seems a pretty serious regression, and I cluelessly assert GPU hang/watchdog as the prime suspect. :P

can you please manually unwind the stack here?

It seems crash reports from ARM boards are busted again.

Gpu watchdog crashes the gpu process not the browser, so it wouldn't require you to log in again.

It looks like there is no code identifier, debug file name and debug identifier for thr chrome module:

module[0]
MDRawModule
  base_of_image                   = 0x30c73000
  size_of_image                   = 0x505a000
  checksum                        = 0x0
  time_date_stamp                 = 0x0 1970-01-01 00:00:00
  module_name_rva                 = 0x5e420
  version_info.signature          = 0x0
  version_info.struct_version     = 0x0
  version_info.file_version       = 0x0:0x0
  version_info.product_version    = 0x0:0x0
  version_info.file_flags_mask    = 0x0
  version_info.file_flags         = 0x0
  version_info.file_os            = 0x0
  version_info.file_type          = 0x0
  version_info.file_subtype       = 0x0
  version_info.file_date          = 0x0:0x0
  cv_record.data_size             = 0
  cv_record.rva                   = 0x0
  misc_record.data_size           = 0
  misc_record.rva                 = 0x0
  (code_file)                     = "/opt/google/chrome/chrome"
  (code_identifier)               = "id"
  (cv_record)                     = (null)
  (misc_record)                   = (null)
  (debug_file)                    = ""
  (debug_identifier)              = ""
  (version)                       = ""

> Chrome re-loads and the user is usually offered the option of Restoring their session

That sounds like a browser process crash.

Re #5: I've filed  issue 691797  for the symbols regression.

Re #6: Thanks Dana; sorry, I thought that the watchdog might be terminating the browser process to get things un-stuck in some situation - my mistake.

Is this observed on the latest 9202.18.0 Beta build?

Re #8: I only have Dev and Canary channel devices right now. I'm only observing the issue on Minnie (ARM).  A colleague was seeing a hang/crash with a Pixel (v1) but they were running Stable, so not sure whether it's the same issue.

After following and tweaking instructions from https://www.chromium.org/chromium-os/packages/crash-reporting/debugging-a-minidump; the best I can seem to come up with is a raw dump of function names on the stack.

Even after converting the minidump back to the core file, I am not able to get a reliable backtrace.


Going by symbols on the stack, this is what we get,

_ZN4base5debug13BreakDebuggerEv+18
_ZN7logging10LogMessageD2Ev+444
_ZN7leveldb5Block4IterD0Ev
_ZN5blink15FloatingObjects6removeEPNS_14FloatingObjectE+840
_ZN7leveldb6StatusC2ENS0_4CodeERKNS_5SliceES4_+166
_ZN8tcmalloc11ThreadCache10DeallocateEPvj+88
_ZN7leveldb7Version3GetERKNS_11ReadOptionsERKNS_9LookupKeyEPSsPNS0_8GetStatsE+488
_ZN7leveldbL9SaveValueEPvRKNS_5SliceES3_
_ZN7leveldbL11NewestFirstEPNS_12FileMetaDataES1_
_ZN4base8internal8LockImpl4LockEv+54
_ZN7leveldb6DBImpl3GetERKNS_11ReadOptionsERKNS_5SliceEPSs+220
_ZN12_GLOBAL__N_19do_mallocEj+160
_ZN8tcmalloc11ThreadCache10DeallocateEPvj+88
_ZN7logging10LogMessage4InitEPKci+268
_ZN4base12_GLOBAL__N_114OnNoMemorySizeEj.constprop.4+92
_ZN4base12_GLOBAL__N_110OnNoMemoryEv
_ZN7leveldb9ReadBlockEPNS_16RandomAccessFileERKNS_11ReadOptionsERKNS_11BlockHandleEPNS_13BlockContentsE+564
_ZN7leveldb5Table11BlockReaderEPvRKNS_11ReadOptionsERKNS_5SliceE+378
_ZNK7content15LevelDBDatabase17ComparatorAdapter7CompareERKN7leveldb5SliceES5_
_ZNK7leveldb5Block4Iter5valueEv
_ZN7leveldb12_GLOBAL__N_116TwoLevelIterator13InitDataBlockEv+130
_ZN7leveldb12_GLOBAL__N_116TwoLevelIterator4SeekERKNS_5SliceE+42
_ZN7leveldb15IteratorWrapper4SeekERKNS_5SliceE+20
_ZN7leveldb12_GLOBAL__N_115MergingIterator4SeekERKNS_5SliceE+42
_ZN7leveldb12_GLOBAL__N_115MergingIterator4SeekERKNS_5SliceE
_ZN7leveldb12_GLOBAL__N_16DBIter4SeekERKNS_5SliceE+118
_ZN7content19LevelDBIteratorImpl4SeekERKN4base16BasicStringPieceISsEE+54
_ZN7content18LevelDBTransaction19TransactionIterator4SeekERKN4base16BasicStringPieceISsEE+58
_ZN7content21IndexedDBBackingStore6Cursor9FirstSeekEPN7leveldb6StatusE+110
_ZN7content21IndexedDBBackingStore21OpenObjectStoreCursorEPNS0_11TransactionExxRKNS_17IndexedDBKeyRangeEN5blink21WebIDBCursorDirectionEPN7leveldb6StatusE+332
_ZN7content17BrowserThreadImpl14PostTaskHelperENS_13BrowserThread2IDERKN15tracked_objects8LocationERKN4base8CallbackIFvvELNS7_8internal8CopyModeE1ELNSA_10RepeatModeE1EEENS7_9TimeDeltaEb+118
_ZN7content17BrowserThreadImpl10InitializeEv+36
_ZN7content17IndexedDBDatabase19OpenCursorOperationESt10unique_ptrINS0_25OpenCursorOperationParamsESt14default_deleteIS2_EEPNS_20IndexedDBTransactionE+312
_ZN7content12IndexedDBKeyD2Ev+38
_ZN4base8internal7InvokerINS0_9BindStateIMN7content17IndexedDBDatabaseEFN7leveldb6StatusESt10unique_ptrINS4_25OpenCursorOperationParamsESt14default_deleteIS8_EEPNS3_20IndexedDBTransactionEEJ13scoped_refptrIS4_ENS0_13PassedWrapperISB_EEEEEFS6_SD_EE3RunEPNS0_13BindStateBaseEOSD_+84
_ZN4base8internal7InvokerINS0_9BindStateIMN7content17IndexedDBDatabaseEFN7leveldb6StatusESt10unique_ptrINS4_25OpenCursorOperationParamsESt14default_deleteIS8_EEPNS3_20IndexedDBTransactionEEJ13scoped_refptrIS4_ENS0_13PassedWrapperISB_EEEEEFS6_SD_EE3RunEPNS0_13BindStateBaseEOSD_
_ZN7content20IndexedDBTransaction16ProcessTaskQueueEv+172
_ZNK4base9TimeDelta14InMillisecondsEv+36
_ZN3exo7wayland12_GLOBAL__N_117NowInMillisecondsEv+44
_ZN4base5debug13TaskAnnotator7RunTaskEPKcPNS_11PendingTaskE+184
_ZN8tcmalloc11ThreadCache21FetchFromCentralCacheEjj+256
_ZN7content20IndexedDBTransaction17RunTasksIfStartedEv+98
_ZN4base11MessageLoop6DoWorkEv+980
_ZN7content20IndexedDBTransaction17RunTasksIfStartedEv+98
_ZN4base13WaitableEvent14TimedWaitUntilERKNS_9TimeTicksE+320
_ZN7content20IndexedDBTransaction16ProcessTaskQueueEv+378
_ZN7content20IndexedDBTransaction16ProcessTaskQueueEv+378
_ZN7content20IndexedDBTransaction17RunTasksIfStartedEv+98
_ZN4base18MessagePumpDefault3RunEPNS_11MessagePump8DelegateE+32
_ZN4base7RunLoop3RunEv+78
_ZN4base6Thread10ThreadMainEv+180
_ZN4base12_GLOBAL__N_110ThreadFuncEPv+66
_ZN4base12_GLOBAL__N_110ThreadFuncEPv


It does look like we start correctly, with the base thread and message loop functions.

*If*, which is a big if, this stack is kinda accurate, it looks like that this is a problem with level6 db.

The calls that lead up the the crash are (trying to clean them up),

base::debug::BreakDebuggerEv+
logging::LogMessageD  Ev+      
leveldb::Block  IterD  Ev
blink::FloatingObjects  removeEPNS_    FloatingObjectE+      
leveldb::StatusC  ENS  _  CodeERKNS_  SliceES  _+      
tcmalloc::ThreadCache    DeallocateEPvj+    
leveldb::Version  GetERKNS_    ReadOptionsERKNS_  LookupKeyEPSsPNS  _  GetStatsE+      
leveldbL::SaveValueEPvRKNS_  SliceES  _
leveldbL::NewestFirstEPNS_    FileMetaDataES  _
base::internal  LockImpl  LockEv+    
leveldb::DBImpl  GetERKNS_    ReadOptionsERKNS_  SliceEPSs+      
do_mallocEj+      
tcmalloc::ThreadCache    DeallocateEPvj+    
logging::LogMessage  InitEPKci+      
base::OnNoMemorySizeEj.constprop.  +    
base::OnNoMemoryEv
leveldb  ReadBlockEPNS_    RandomAccessFileERKNS_    ReadOptionsERKNS_    BlockHandleEPNS_    BlockContentsE+      
leveldb  Table    BlockReaderEPvRKNS_    ReadOptionsERKNS_  SliceE+      
_ZNK  content::LevelDBDatabase    ComparatorAdapter  CompareERKN  leveldb  SliceES  _
_ZNK  leveldb  Block  Iter  valueEv
leveldb::TwoLevelIterator    InitDataBlockEv+      
leveldb::TwoLevelIterator  SeekERKNS_  SliceE+    
leveldb::IteratorWrapper  SeekERKNS_  SliceE+    
leveldb::MergingIterator  SeekERKNS_  SliceE+    
leveldb::MergingIterator  SeekERKNS_  SliceE
leveldb::_GLOBAL__N_    DBIter  SeekERKNS_  SliceE+      
content::LevelDBIteratorImpl  SeekERKN  base    BasicStringPieceISsEE+    
content::LevelDBTransaction    TransactionIterator  SeekERKN  base    BasicStringPieceISsEE+    
content::IndexedDBBackingStore  Cursor  FirstSeekEPN  leveldb  StatusE+      
content::IndexedDBBackingStore    OpenObjectStoreCursorEPNS  _    TransactionExxRKNS_    IndexedDBKeyRangeEN  blink    WebIDBCursorDirectionEPN  leveldb  StatusE+      
content::BrowserThreadImpl    PostTaskHelperENS_    BrowserThread  IDERKN    tracked_objects  LocationERKN  base  CallbackIFvvELNS  _  internal  CopyModeE  ELNSA_    RepeatModeE  EEENS  _  TimeDeltaEb+      
content::BrowserThreadImpl    InitializeEv+


Can anyone make sense of this?

djkurtz@/groeck@ - Is this something you can take a look at? This is currently beta blocking. Moving this to Stable till we confirm this is repro on beta as well.

#11: Not me. I don't know anything about chrome, and as far as I can see there is no kernel log available (which might tell us if the system is running out of memory or if there is a problem ineracting with the hardware).

folks, is the the same leveldb problem as issue 690517?

The stack looks very similar to the manually decoded stack in the partner tracker: https://code.google.com/p/chrome-os-partner/issues/detail?id=62731#c24

Yeah, we can dupe to 690517 

+dahlke, FYI