Stop Cobalt will hang(block) indefinitely - cobalt

Question

Cobalt will hang(block) indefinitely after calling the ApplicationDirectFB::Get()->Stop() function, and can not exit, and the backtrace when hung is as follows, could anyone help to have a look?
<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]
If I comment the no_flushes_pending_.Wait(); in StorageManager::FinishIO in src/cobalt/storage/storage_manager.cc, it will not hung(block), and can exit successfully
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

This is not the best answer because I only vaguely remember encountering this before, but I couldn't find the reference to it anywhere to confirm. I believe this happens when one of the SbStorage APIs doesn't return the right value, perhaps on an error?

Answer 2

The root cause is that it will write data to $HOME/.starboard.storage(which is set in starboard/shared/linux/get_home_directory.cc), but on some platform, the partition is read only, and it will make the write failed and hang indefinitely, so it need to change the file path of .starboard.storage to some writeable partition.