Crash at lfs_fs_traverse()

[liconghui628]

Hello everyone，
I'm encountering a program crash issue, call stack as follows:
[
exception_entry 于 bl_irq.c:397
is_exception 于 portable/GCC/RISC-V/portASM.S:355
?? ??:0
lfs_fs_traverse 于 littlefs/littlefs/lfs.c:3755 (dicriminator 1) // Line 3755 is lfs_dir_fetch()
lfs_alloc 于 littlefs/littlefs/lfs.c:484
lfs_ctz_extend 于 littlefs/littlefs/lfs.c:2174
log_write 于 littlefs/log/miio_log.c:116 //This is the interface I implemented myself
]

The version I am using is 2.1. At the beginning, it was normal, but after the problem occurred, even every time the power was turned on and restarted, it would crash here. Here are some configurations for Littlefs.

const struct lfs_config lfscfg = {
// block device operations
.read = milfs_flash_read,
.prog = milfs_flash_prog,
.erase = milfs_flash_erase,
.sync = milfs_flash_sync,

// block device configuration
.block_size = 4096,
.block_count = 20,
.read_size = 512,
.prog_size = 16,
.cache_size = 512,
.lookahead_size = 16,
.block_cycles = 500,

};

Can anyone help me? Thank you very much.

[liconghui628]

lfs.c

I found a problem, the function lfs_dir_fetchmatch in the lfs. c file, calling callback function does not determine if the cb is NULL. The crash occurs during the cb call, becase the cb is NULL.
Is this a konwn problem?

static int lfs_dir_fetch(lfs_t *lfs,
        lfs_mdir_t *dir, const lfs_block_t pair[2]) {
        // note, mask=-1, tag=-1 can never match a tag since this
        // pattern has the invalid bit set
       return (int)lfs_dir_fetchmatch(lfs, dir, pair,
                (lfs_tag_t)-1, (lfs_tag_t)-1, NULL, NULL, NULL);
}

static lfs_stag_t lfs_dir_fetchmatch(lfs_t *lfs,
        lfs_mdir_t *dir, const lfs_block_t pair[2],
        lfs_tag_t fmask, lfs_tag_t ftag, uint16_t *id,
        int (*cb)(void *data, lfs_tag_t tag, const void *buffer), void *data) {
            ......

            // found a match for our fetcher?
            if ((fmask & tag) == (fmask & ftag)) {
                int res = cb(data, tag, &(struct lfs_diskoff){
                        dir->pair[0], off+sizeof(tag)});
                if (res < 0) {
                    if (res == LFS_ERR_CORRUPT) {
                        dir->erased = false;
                        break;
                    }
                    return res;
                }

            ......
}

[BenBE]

Does the documentation mention that this argument is required and that it must be non-NULL?

AFAICS it does not.

Does the code inside the function make sense to be executed with cb set to NULL?

As the return value from calling cb is used to drive decisions that aren't made otherwise, it is required AFAICS.
Thus providing a non-NULL value for cb is required by the code.

Does other code call it with cb==NULL?

Surprisingly: Yes.

[liconghui628]

Yes, lfs_dir_fetchmatch is an interface called internally by Littlefs and will not be called by external interfaces. I want to know under what circumstances will I reach this branch while writing a file? Because it didn't appear from the beginning.
So is this a known problem? I really want to know if it would have any impact if I were to determine that cb is NULL in this interface and not execute the relevant calls, And, if any fixes have been made for this issue in which version?

[BenBE]

Looking at

littlefs/lfs.c

Lines 1387 to 1393 in adad0fb

	static int lfs_dir_fetch(lfs_t *lfs,
	lfs_mdir_t *dir, const lfs_block_t pair[2]) {
	// note, mask=-1, tag=-1 can never match a tag since this
	// pattern has the invalid bit set
	return (int)lfs_dir_fetchmatch(lfs, dir, pair,
	(lfs_tag_t)-1, (lfs_tag_t)-1, NULL, NULL, NULL);
	}

we enter lfs_dir_fetchmatch with ftag==-1 and fmask==-1, i.e. both having all bits set.

The crash later happens in

littlefs/lfs.c

Lines 1292 to 1301 in adad0fb

	// found a match for our fetcher?
	if ((fmask & tag) == (fmask & ftag)) {
	int res = cb(data, tag, &(struct lfs_diskoff){
	dir->pair[0], off+sizeof(tag)});
	if (res < 0) {
	if (res == LFS_ERR_CORRUPT) {
	break;
	}
	return res;
	}

which only is reached if while reading the directory we encounter tag==-1, which is, as far as I remember the spec, only happens for unprogrammed flash or an invalid directory state.

Can you somehow provide a copy/dump of that faulty filesystem for further debugging?

@geky AFAICT, the place where the tag is checked we expect valid data, which is not the case. Given the call in lfs_dir_fetch provides placeholder values for the ftag might be treated as a sign to ignore the callback. A more robust check would amend

 if ((fmask & tag) == (fmask & ftag) && cb) {

in line 1293 which makes the overall API semantics treat cb==NULL as "match none" and thus "dirscan only".

[liconghui628]

Provide a copy/dump of that faulty filesystem is difficult now.
I am conducting a power down test, and after running for a period of time, this problem will occur.

[geky]

Per conversation in #1159: I believe this is a duplicate of #184, which was fixed in #337 and merged into v2.1.4.