Google Summer of Code | malloc_info() changes the state of the heap (#41)
Anshika Gupta (@anshika_gupta)
gitlab at rtems.org
Thu Feb 26 20:55:14 UTC 2026
Anshika Gupta commented: https://gitlab.rtems.org/rtems/programs/gsoc/-/issues/41#note_143587
@gedare @chris
Yuh, I could locate that call of `_Heap_Get_Information()` and could see that it is calling `_Heap_Protection_free_all_delayed_blocks()`. I rebuilt the zynqmp_qemu with` RTEMS_DEBUG = True` which **enabled the Heap_Protection** and changed my hello.c code such that I initially allocated memory and then freed it and printed the `delayed_free_block_count` which was equal to **5**. After calling malloc_info once, the **delayed_free_block_count decreased to 0** showing that malloc_info() is freeing the delayed blocks which I think recreates the issue of "malloc_info changes the state of the heap". Could you please confirm whether this counts as recreating the issue and should I start writing the proposal for this project?
My Output
```
anshikagupta at Anshikas-MacBook-Pro hello % qemu-system-aarch64 \
-machine xlnx-zcu102 \
-m 1024 \
-nographic \
-no-reboot \
-kernel build/aarch64-rtems7-zynqmp_qemu/hello.exe
HEAP_PROTECTION is ENABLED
delayed_free_block_count = 5
Stats after first malloc_info
Heap Information
Free blocks : 1
Free largest : 1071307712 bytes
Free total : 1071307712 bytes
Used blocks : 14
Used largest : 8384 bytes
Used total : 20640 bytes
Heap Statistics
Lifetime alloc : 26160 bytes
Lifetime freed : 5520 bytes
Current free : 1071307712 bytes
Free blocks stat : 1
Used blocks stat : 14
delayed_free_block_count = 0
Stats after second malloc info
Heap Information
Free blocks : 1
Free largest : 1071307712 bytes
Free total : 1071307712 bytes
Used blocks : 14
Used largest : 8384 bytes
Used total : 20640 bytes
Heap Statistics
Lifetime alloc : 26160 bytes
Lifetime freed : 5520 bytes
Current free : 1071307712 bytes
Free blocks stat : 1
Used blocks stat : 14
delayed_free_block_count = 0
[ RTEMS shutdown ]
RTEMS version: 7.0.0.e5eaa824202a3760d508012b13b9df45c43e670c
RTEMS tools: 15.2.0 20250808 (RTEMS 7, RSB 424f142d70c97ca4e498e58d666d798c9de4a264, Newlib 038afec1)
executing thread ID: 0x0a010001
executing thread name: UI1
```
The hello.c code I used
```
#include <rtems/confdefs.h>
#include <rtems/malloc.h>
#include <rtems/libcsupport.h>
#include <rtems/score/heapinfo.h>
#include <rtems/score/heapimpl.h>
static void print_info(Heap_Information_block *info)
{
printf("Heap Information\n");
printf(" Free blocks : %zu\n", info->Free.number);
printf(" Free largest : %zu bytes\n", info->Free.largest);
printf(" Free total : %zu bytes\n", info->Free.total);
printf(" Used blocks : %zu\n", info->Used.number);
printf(" Used largest : %zu bytes\n", info->Used.largest);
printf(" Used total : %zu bytes\n", info->Used.total);
printf("Heap Statistics\n");
printf(" Lifetime alloc : %llu bytes\n",
info->Stats.lifetime_allocated);
printf(" Lifetime freed : %llu bytes\n",
info->Stats.lifetime_freed);
printf(" Current free : %zu bytes\n",
info->Stats.free_size);
printf(" Free blocks stat : %u\n",
info->Stats.free_blocks);
printf(" Used blocks stat : %u\n",
info->Stats.used_blocks);
}
#ifdef HEAP_PROTECTION
static void print_delayed()
{
printf("delayed_free_block_count = %d\n", RTEMS_Malloc_Heap->Protection.delayed_free_block_count);
}
#endif
rtems_task Init(rtems_task_argument ignored)
{
#ifdef HEAP_PROTECTION
printf("HEAP_PROTECTION is ENABLED\n");
#else
printf("HEAP_PROTECTION is NOT ENABLED\n");
#endif
void *ptrs[5];
Heap_Information_block before;
Heap_Information_block after;
for (int i = 0; i < 5; i++) {
ptrs[i] = malloc(1024);
}
for (int i = 0; i < 5; i++) {
free(ptrs[i]);
}
#ifdef HEAP_PROTECTION
print_delayed();
#endif
malloc_info(&before);
printf("Stats after first malloc_info\n");
print_info(&before);
#ifdef HEAP_PROTECTION
print_delayed();
#endif
malloc_info(&after);
printf("Stats after second malloc info\n");
print_info(&after);
#ifdef HEAP_PROTECTION
print_delayed();
#endif
exit(0);
}
```
--
View it on GitLab: https://gitlab.rtems.org/rtems/programs/gsoc/-/issues/41#note_143587
You're receiving this email because of your account on gitlab.rtems.org.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.rtems.org/pipermail/bugs/attachments/20260226/93ef6c34/attachment-0001.htm>
More information about the bugs
mailing list