On 10/10/20 7:35 am, Alan Cudmore wrote: > After doing a lot of tracing through my application, it looks like > malloc_info works fine before we start our cFS application, but it > blocks after the cFS is initialized. This suggests some sort of memory > corruption. > I started by instrumenting our code to call malloc info during various > stages of application initialization, and finally narrowed it down to > the code where we create a RAM Disk and format it with RFS. > (skipping a bunch of other malloc based troubleshooting.. ) > After I followed the issue into the RFS init, I was able to narrow > down the place where malloc_info stopped working to here: > https://git.rtems.org/rtems/tree/cpukit/libfs/src/rfs/rtems-rfs-bitmaps.c?h=5#n637 > During the RFS format process. > In this section of the code, the size variable is 0, meaning it will > exit the for loop and then return from the function, but it increments > the "search_map" variable and writes to memory through the pointer one > more time before exiting the loop and function. It's at this point > where malloc_info starts blocking. > > It seems to me that this if block should be skipped when size == 0. I > tried that and the malloc_info issue seems to be fixed.
Would you be able to create a test case for this? The test is .. https://git.rtems.org/rtems/tree/testsuites/fstests/fsrfsbitmap01/test.c Or if you could please provide the values in `control` I can add the test. > Is this an RFS bug writing into other memory, or is this last write > needed before the function updates? It would seem so. > If this looks like a bug, should I write a ticket and provide a patch? Yes please. It would be nice to have a test case that fails so we can isolate the cause. Chris _______________________________________________ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
