Stop Cobalt将无限期挂起(阻止)

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]

如果我在src/cobalt/storage/storage_manager.cc中注释StorageManager::FinishIO中的no_flushes_pending_.Wait();，它将不会挂起(阻塞)，并且可以成功退出

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

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

Answer 2

这不是最好的答案，因为我只模糊地记得以前遇到过这个问题，但我在任何地方都找不到它的参考资料来证实。我相信当某个SbStorage API没有返回正确的值时会发生这种情况，可能是因为错误？