Question

Cobalt将在调用ApplicationDirectFB::Get()->Stop()函数后无限期挂起（阻塞），并且无法退出，挂起时的回溯如下所示，任何人都可以帮忙看看吗？

        <unknown> [0xb5d988f4]
        SbConditionVariableWait [0xbd598]
        base::WaitableEvent::TimedWait() [0xa0f1c]
        base::WaitableEvent::Wait() [0xa0ff8]
        cobalt::storage::StorageManager::FinishIO() [0x374454]
        cobalt::storage::StorageManager::~StorageManager() [0x374750]
        cobalt::storage::StorageManager::~StorageManager() [0x374750]
        cobalt::storage::StorageManager::~StorageManager() [0x374750]
        cobalt::storage::StorageManager::~StorageManager() [0x374750]
        cobalt::storage::StorageManager::~StorageManager() [0x374750]
        cobalt::storage::StorageManager::~StorageManager() [0x374750]
        cobalt::storage::StorageManager::~StorageManager() [0x374750]
        cobalt::storage::StorageManager::~StorageManager() [0x374750]
        cobalt::storage::StorageManager::~StorageManager() [0x374750]
        cobalt::storage::StorageManager::~StorageManager() [0x374750]
        cobalt::storage::StorageManager::~StorageManager() [0x374750]
        cobalt::storage::StorageManager::~StorageManager() [0x374750]
        cobalt::storage::StorageManager::~StorageManager() [0x374750]
        cobalt::storage::StorageManager::~StorageManager() [0x374750]
        cobalt::storage::StorageManager::~StorageManager() [0x374750]
        cobalt::storage::StorageManager::~StorageManager() [0x374750]

如果我对no_flushes_pending_.Wait();中的StorageManager::FinishIO中的src/cobalt/storage/storage_manager.cc发表评论，它将不会挂起（阻止），并且可以成功退出

void StorageManager::FinishIO() {
  TRACE_EVENT0("cobalt::storage", __FUNCTION__);
  DCHECK(!sql_message_loop_->BelongsToCurrentThread());
  // The SQL thread may be communicating with the savegame I/O thread still,
  // flushing all pending updates.  This process can require back and forth
  // communication.  This method exists to wait for that communication to
  // finish and for all pending flushes to complete.
  // Start by finishing all commands currently in the sql message loop queue.
  // This method is called by the destructor, so the only new tasks posted
  // after this one will be generated internally.  We need to do this because
  // it is possible that there are no flushes pending at this instant, but there
  // are tasks queued on |sql_message_loop_| that will begin a flush, and so
  // we make sure that these are executed first.
  base::WaitableEvent current_queue_finished_event_(true, false);
  sql_message_loop_->PostTask(
      FROM_HERE,
      base::Bind(&base::WaitableEvent::Signal,
                 base::Unretained(&current_queue_finished_event_)));
  current_queue_finished_event_.Wait();
  // Now wait for all pending flushes to wrap themselves up.  This may involve
  // the savegame I/O thread and the SQL thread posting tasks to each other.
  //no_flushes_pending_.Wait();  -->Comment it
}

Answer 1

这不是最好的答案，因为我之前只是模糊地记得遇到过这种情况，但我无法在任何地方找到它的引用来确认。我相信当其中一个SbStorage API没有返回正确的值（可能出错）时会发生这种情况？

Answer 2

根本原因是它会将数据写入$HOME/.starboard.storage（在starboard/shared/linux/get_home_directory.cc中设置），但在某些平台上，该分区是只读的，它会使写入失败并挂起无限期，因此需要将.starboard.storage的文件路径更改为某个可写分区。

停止Cobalt会无限期地挂起（阻止）

2 个答案: