Closed robert-hh closed 2 years ago
Carrying over the way mp.org is doing that, changing the section for close in vfs_littlefs_file.x, line 102cc prohibits closing a closed file. Next candidate for a PR.
} else if (request == MP_STREAM_CLOSE) {
if (self->littlefs == NULL) {
return 0;
}
xSemaphoreTake(self->littlefs->mutex, portMAX_DELAY);
int res = littlefs_close_common_helper(&self->littlefs->lfs, &self->fp, &self->cfg, &self->timestamp_update);
xSemaphoreGive(self->littlefs->mutex);
self->littlefs = NULL; // indicate a closed file
if (res < 0) {
*errcode = littleFsErrorToErrno(res);
return MP_STREAM_ERROR;
}
return 0;
Version 1.20.2.r4, although I guess that this does not matter The three code lines below cause a crash by abort() being called by RTOS. The same code snippet behaves well with FAT, behaves well with LFS on micropython.org firmware. A dir(f) call after the first f.close() causes the firmware to freeze. On mp.org firmware, it still shows the file methods. That indicates that the file object gets corrupted on close. Until now, I did not find the place where that happens. Even if closing a file twice is not reasonable, the firmware should be able to deal with it, either by ignoring or raising an error. Code lines:
start of decoded trace dump: