Anshika Gupta commented on a discussion: https://gitlab.rtems.org/rtems/programs/gsoc/-/issues/41#note_144278 @gedare I do agree with the idea of consolidating calls to explicit allocation/deallocation paths, but upon removing the call of \_Heap_Protection_free_all_delayed_blocks() from \_Heap_Get_information(), the delayed blocks aren't freed and the \_Heap_Get_Information() reports the delayed blocks as used and I do think just adding calls to free delayed blocks would help but won't the heap details be misleading because it counts blocks flushed by user as used and one would be expecting memory to be free. So, I was thinking, that in addition to consolidating calls to allocation paths, how about we also add an attribute to the struct `Heap_Information_block` which stores the info about delayed blocks and its count ensuring that the Heap_Information_Block isn't counting delayed blocks as used when Heap_Get_information() is called. As of now there is no attribute in the struct Heap_Information_Block for delayed blocks: ``` typedef struct { Heap_Information Free; Heap_Information Used; Heap_Statistics Stats; } Heap_Information_block; ``` And another thought I had was making the free() call return a string saying "Freeing of blocks got delayed because of active HEAP_PROTECTION, allocate more memory to free the memory!" or would it be better to just add it to the documentation? -- View it on GitLab: https://gitlab.rtems.org/rtems/programs/gsoc/-/issues/41#note_144278 You're receiving this email because of your account on gitlab.rtems.org.
_______________________________________________ bugs mailing list [email protected] http://lists.rtems.org/mailman/listinfo/bugs
