RTEMS 5.1 pc686 BSP malloc_info problem?

[Alan Cudmore]

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.

Is this an RFS bug writing into other memory, or is this last write
needed before the function updates?

If this looks like a bug, should I write a ticket and provide a patch?

Thanks,
Alan

On Mon, Oct 5, 2020 at 1:06 PM Joel Sherrill <joel at rtems.org> wrote:
>
>
>
> On Mon, Oct 5, 2020 at 11:07 AM Alan Cudmore <alan.cudmore at gmail.com> wrote:
>>
>> I built the tools shortly after the announced 5.1 release. I'm using
>> the 5.1 branches for everything.
>> But some additional info..I built the full testsuite, and ran the
>> malloctest with no problems. It calls malloc_info a couple of times.
>>
>> I also compiled my RTEMS Kernel Image (RKI) for this BSP and the
>> "malloc info" shell command works on that. This is the same way I
>> tested the sparc/leon3 BSP so at least that is consistent.
>>
>> This has to come down to a configuration issue for the application
>> (core flight system pc-rtems test platform)
>> I'm going to check over the configuration options and compiler options
>> used. It will most likely be another case of user error, which I
>> prefer!
>
>
> This wouldn't be a user error. Just a case where the bug was found
> after the release. :)
>
> --joel
>>
>>
>> Thanks,
>> Alan
>>
>> On Mon, Oct 5, 2020 at 11:58 AM Joel Sherrill <joel at rtems.org> wrote:
>> >
>> >
>> >
>> > On Mon, Oct 5, 2020 at 10:34 AM Gedare Bloom <gedare at rtems.org> wrote:
>> >>
>> >> This is an SMP related bug?  Can you send the rtems configure command,
>> >> and the qemu run command?
>> >>
>> >> It might also help to know the number of tasks and their priorities.
>> >> The CONFIGURE* macros might also help.
>> >>
>> >> My first guess is that the lock primitive is somehow broken in the
>> >> pc686, maybe it gets caught in a buggy CAS/TAS loop? It would help if
>> >> you can narrow down the task spinning to a particular section of code
>> >> and send the disassembly (or file/line if it is in RTEMS)
>> >
>> >
>> > Hmmm.. When did you build your i386 tools? git says 9/19 for the last change
>> > but it was very much likely a few days after that when I pushed it.
>> >
>> > --joel
>> >>
>> >>
>> >> On Sun, Oct 4, 2020 at 2:06 PM Alan Cudmore <alan.cudmore at gmail.com> wrote:
>> >> >
>> >> > Hi,
>> >> > I have a problem in RTEMS 5.1 where the pc686 running on QEMU seems to
>> >> > block or spin when trying to acquire a lock for the malloc_info call.
>> >> > The CPU utilization goes up to 100 (on the QEMU host) leading me to
>> >> > think the calling task is spinning waiting on the lock. Tasks with
>> >> > lower priority than the calling task stop running as well. I also get
>> >> > this problem when running the "malloc info" shell command.
>> >> > I don't see this problem with the leon3 BSP built from the same source
>> >> > tree and executed on QEMU.
>> >> >
>> >> > Is there an SMP related initialization or perhaps QEMU option I might
>> >> > be missing? I can run the same code without problems on the RTEMS 4.11
>> >> > release (same QEMU binary and QEMU options)
>> >> >
>> >> > Thanks,
>> >> > Alan
>> >> > _______________________________________________
>> >> > devel mailing list
>> >> > devel at rtems.org
>> >> > http://lists.rtems.org/mailman/listinfo/devel
>> >> _______________________________________________
>> >> devel mailing list
>> >> devel at rtems.org
>> >> http://lists.rtems.org/mailman/listinfo/devel