Robert

since commit f5e26c4e933189593a71c6b82cda381a7b21e41c (fixes #165) i have memory overwrites. i have not yet tested version 0.4.0.

I was two weeks off - I have not tested any newer commit. The application is a simple logger app which writes numerous large files.  Row 16 shows an...

hmmm, I'm getting older ... For shure commit 7f31842b837445004e62bd92d4d6ee4532eec194 hasn't the internal 'overwrite' bug. I updated inbetween ... but I'm facing a dangling pointer when I did so ...

Yes, the commit is old. I am re-running a test - when finished I can say more. The dangling pointer is somewhere between my ears. I can't remember when I...

I went back to the SPIFFSversion from the 4.th of august 2017. The 'overwrite' happens during the SPIFFS_open call only. Need a few more Tests - also with the latest...

I went further back - version v0.3.6. The same problem... Need some ideas.

I did run the linux_spiffs_test using valgrind - the valgrind output is not so amusing. Can you do the same? ==10301== LEAK SUMMARY: ==10301== definitely lost: 0 bytes in 0...

Valgrind reports a problem in the test code: TEST 2/89 : running test lu_check1 create and write file check: LOOKUP FIX INDEX 0001:0001 check: LOOKUP DELETE PAGE 0006 .. ok...

when the memory layout changes valgrind reports other locations ... when running the test under gdb i'm getting: ran 89 tests Test report, 89 tests 85 succeeded 4 failed write_big_files_chunks_page...

@pjsg I created a pull request. The function "spiffs_create_object" did rely on unitialized memory. My problem seems to be solved - need a longer test run to be sure.