ChibiOS OS Library Test Suite

[vrollei]

Hi,

ChibiOS OS Library Test Suite Test Case 9.5 (Dynamic Objects FIFOs Factory) constantly fails after about 100 iterations.
Is it possible to use oslib_test_suite inside loop?

*** ChibiOS OS Library Test Suite
***
*** Compiled:     Nov 17 2020 - 15:43:13
*** Platform:     STM32L4xx Ultra Low Power
*** Test Board:   XBOARD
***
*** Text size:    52184 bytes
*** RO data size: 13104 bytes
*** Data size:    332 bytes
*** BSS size:     8520 bytes

----------------------------------------------------------------------------
--- Test Case 9.5 (Dynamic Objects FIFOs Factory)
--- Result: FAILURE (#2 [] "cannot create")
----------------------------------------------------------------------------

[Giovanni]

This could be caused by memory fragmentation, the factory uses memory allocation, check the heap state using the "mem" shell command.

Giovanni

[vrollei]

Will check it, is there any way to clean up memory after test cases execution?
Thanks!

[Giovanni]

Will check it, is there any way to clean up memory after test cases execution?
Thanks!

Currently not, it would require resetting the heap state which could create unintended consequences. You may try calling again the memory allocators initializers which are not an official API.

Giovanni

[FXCoder]

Hi,
I just did a quick check on a L432 NUCLEO and found main memory decreased after each 'test oslib'.
Could it be that a factory object is not being released (left dangling with heap allocated)?
--
Bob

[Giovanni]

Hi,
I just did a quick check on a L432 NUCLEO and found main memory decreased after each 'test oslib'.
Could it be that a factory object is not being released (left dangling with heap allocated)?
--
Bob

It is possible, do you know in which test case this happens?

Giovanni

[vrollei]

Hi,

Memory usage trace:

============================================================================
=== Test Sequence 9 (Objects Factory)
----------------------------------------------------------------------------
--- Test Case 9.1 (Objects Registry)
--- Result: SUCCESS
00:03:02.494 DEBUG main.c::print_mem:51  - core free memory : 50696 bytes
00:03:02.522 DEBUG main.c::print_mem:52  - heap fragments   : 1
00:03:02.548 DEBUG main.c::print_mem:53  - heap free total  : 552 bytes
00:03:02.576 DEBUG main.c::print_mem:54  - heap free largest: 552 bytes
----------------------------------------------------------------------------
--- Test Case 9.2 (Dynamic Buffers Factory)
--- Result: SUCCESS
00:03:02.836 DEBUG main.c::print_mem:51  - core free memory : 50696 bytes
00:03:02.864 DEBUG main.c::print_mem:52  - heap fragments   : 1
00:03:02.890 DEBUG main.c::print_mem:53  - heap free total  : 136 bytes
00:03:02.917 DEBUG main.c::print_mem:54  - heap free largest: 136 bytes
----------------------------------------------------------------------------
--- Test Case 9.3 (Dynamic Semaphores Factory)
--- Result: SUCCESS
00:03:03.179 DEBUG main.c::print_mem:51  - core free memory : 50696 bytes
00:03:03.207 DEBUG main.c::print_mem:52  - heap fragments   : 1
00:03:03.232 DEBUG main.c::print_mem:53  - heap free total  : 136 bytes
00:03:03.260 DEBUG main.c::print_mem:54  - heap free largest: 136 bytes
----------------------------------------------------------------------------
--- Test Case 9.4 (Dynamic Mailboxes Factory)
--- Result: SUCCESS
00:03:03.521 DEBUG main.c::print_mem:51  - core free memory : 50696 bytes
00:03:03.549 DEBUG main.c::print_mem:52  - heap fragments   : 1
00:03:03.575 DEBUG main.c::print_mem:53  - heap free total  : 136 bytes
00:03:03.603 DEBUG main.c::print_mem:54  - heap free largest: 136 bytes
----------------------------------------------------------------------------
--- Test Case 9.5 (Dynamic Objects FIFOs Factory)
--- Result: SUCCESS
00:03:03.865 DEBUG main.c::print_mem:51  - core free memory : 50280 bytes
00:03:03.893 DEBUG main.c::print_mem:52  - heap fragments   : 1
00:03:03.918 DEBUG main.c::print_mem:53  - heap free total  : 552 bytes
00:03:03.946 DEBUG main.c::print_mem:54  - heap free largest: 552 bytes

Core free memory decreases after each iteration:

00:08:04.790 DEBUG main.c::print_mem:51  - core free memory : 47784 bytes
00:08:04.818 DEBUG main.c::print_mem:52  - heap fragments   : 1
00:08:04.844 DEBUG main.c::print_mem:53  - heap free total  : 552 bytes
00:08:04.871 DEBUG main.c::print_mem:54  - heap free largest: 552 bytes
--------------------------------------------------------------------------

[FXCoder]

Hi Giovanni,
I started looking into the memory leak based on data Vitaly provided and the Objects FIFO tests in particular.
One thing I noticed first up is what looks like an issue with undersized heap being allocated for aligned objects.
When allocating heap shouldn't the object size be rounded up to the object alignment requirement?

The actual memory leak problem is another matter TBD.
--
Bob

Code: Select all

dyn_objects_fifo_t *chFactoryCreateObjectsFIFO(const char *name,
                                               size_t objsize,
                                               size_t objn,
                                               unsigned objalign) {
  dyn_objects_fifo_t *dofp;

  F_LOCK();

// Round up object size to aligned size here...
  dofp = (dyn_objects_fifo_t *)dyn_create_object_heap(name,
                                                      &ch_factory.fifo_list,
                                                      sizeof (dyn_objects_fifo_t) +
                                                      (objn * sizeof (msg_t)) +
                                                      (objn * objsize));
  if (dofp != NULL) {
    msg_t *msgbuf = (msg_t *)(dofp + 1);

    /* Initializing mailbox object data.*/
    chFifoObjectInitAligned(&dofp->fifo, objsize, objn, objalign,
                            (void *)&msgbuf[objn], msgbuf);
  }

  F_UNLOCK();

  return dofp;
}

[FXCoder]

I tested with a non-aligned object size and hit the assert at chFifoObjectInitAligned(...) line 128.
I used the following macro to round up object size in chFactoryCreateObjectsFIFO(...) and all is OK.

Code: Select all

  objsize = MEM_ALIGN_NEXT(objsize, objalign);

--
Bob

[FXCoder]

Hi Giovanni and Vitaly,
#1 The memory leak
It no longer appears when I run test oslib on the same L432 board+code that I tested on previously.
So it is not clear if other recent OS change(s) may have cured the memory leak.

Vitaly - could you run your tests again on the latest trunk please?

#2 The alignment bug/fix
This is not related to the memory leak (I tested for the leak with and without the alignment fix).
The alignment fix needs to be applied in any case.

Giovanni - If you are OK with my fix I will raise a bug report and apply the fix to trunk and 20.3.x.
--
Bob