I will look into this.
Giovanni
ChibiOS OS Library Test Suite
- Giovanni
- Site Admin
- Posts: 14444
- Joined: Wed May 27, 2009 8:48 am
- Location: Salerno, Italy
- Has thanked: 1074 times
- Been thanked: 921 times
- Contact:
- FXCoder
- Posts: 384
- Joined: Sun Jun 12, 2016 4:10 am
- Location: Sydney, Australia
- Has thanked: 180 times
- Been thanked: 130 times
Re: ChibiOS OS Library Test Suite
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
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
- Site Admin
- Posts: 14444
- Joined: Wed May 27, 2009 8:48 am
- Location: Salerno, Italy
- Has thanked: 1074 times
- Been thanked: 921 times
- Contact:
Re: ChibiOS OS Library Test Suite
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:
A dumb error....
The problem is restricted to that function, the rest of the factory is fine.
Giovanni
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
Re: ChibiOS OS Library Test Suite
Hi,
now it works fine!
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.
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.
Vitaly
- Giovanni
- Site Admin
- Posts: 14444
- Joined: Wed May 27, 2009 8:48 am
- Location: Salerno, Italy
- Has thanked: 1074 times
- Been thanked: 921 times
- Contact:
Re: ChibiOS OS Library Test Suite
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
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
Who is online
Users browsing this forum: No registered users and 6 guests