ChibiOS OS Library Test Suite

[Giovanni]

I will look into this.

Giovanni

[FXCoder]

Hi,
Factory FIFO fix tested OK on work project.
I switched to a different board (WB55) at work and ran the test oslib suite and found the leak has returned versus the L432 project I ran last week.
It loses 416 bytes per iteration.
--
Bob

[Giovanni]

I committed a fix, it was not an overflow but a memory corruption that caused free blocks to not be returned to the heap (the overflow cleared the block header of the next adjacent block). We detected is as a leak but it could have caused any kind of trouble using the function chFactoryCreateBuffer().

Changed as follow:

Code: Select all

dyn_buffer_t *chFactoryCreateBuffer(const char *name, size_t size) {
  dyn_buffer_t *dbp;

  F_LOCK();

  dbp = (dyn_buffer_t *)dyn_create_object_heap(name,
                                               &ch_factory.buf_list,
                                               sizeof (dyn_buffer_t) + size,
                                               CH_HEAP_ALIGNMENT);
  if (dbp != NULL) {
    /* Initializing buffer object data.*/
    memset((void *)(dbp + 1), 0, size);
  }

  F_UNLOCK();

  return dbp;
}

A dumb error....

The problem is restricted to that function, the rest of the factory is fine.

Giovanni

[vrollei]

Hi,

now it works fine!

00:00:38.314 DEBUG main.c::print_mem:51  - core free memory : 56216 bytes
00:00:38.342 DEBUG main.c::print_mem:52  - heap fragments   : 2
00:00:38.367 DEBUG main.c::print_mem:53  - heap free total  : 552 bytes
00:00:38.395 DEBUG main.c::print_mem:54  - heap free largest: 408 bytes
00:00:38.423 DEBUG main.c::main:194 - Iteration: 1 Errors: 0

...

00:37:40.363 DEBUG main.c::print_mem:51  - core free memory : 56216 bytes
00:37:40.391 DEBUG main.c::print_mem:52  - heap fragments   : 2
00:37:40.417 DEBUG main.c::print_mem:53  - heap free total  : 552 bytes
00:37:40.445 DEBUG main.c::print_mem:54  - heap free largest: 408 bytes
00:37:40.472 DEBUG main.c::main:194 - Iteration: 56 Errors: 0

But there is strange warning during build with trunk version:

lto-wrapper: warning: Options to Xassembler do not match: -alms=./build/lst/crt1.lst, -alms=./build/lst/hal.lst, dropping all -Xassembler and -Wa options.

[Giovanni]

That warning is a GCC 10 bug I believe, it complains that 2 modules have different asm options, the only difference is the .lst file name. If you force the same name for all files the warning disappears.

It also says that options are dropped but this is not the case, the .lst files are generated as expected.

I will backport the registry fixes to previous versions.

Giovanni