On 12/1/21 7:42 AM, tito wrote:
It can matter: consider large tar files on memory constrained devices. tar may fail to complete correctly, due to running out of memory, and in the process of running out of memory, may invoke the OOM killer in the process, which might kill some other process. AriadneHi, // Die if we can't allocate size bytes of memory. void* FAST_FUNC xmalloc(size_t size) { void *ptr = malloc(size); if (ptr == NULL && size != 0) bb_die_memory_exhausted(); return ptr; } Ciao, Tito
A stock Linux system will happily slaughter your system services with the OOM killer before malloc ever returns NULL.
In fact, I think the only way I've ever seen a program get NULL from malloc is if it exhausts 32-bit address space.
But, anyone assembling a embedded system has to be aware of the proper way to configure the OOM killer to kill the correct things first, so tar shouldn't be running with any privileges that would cause a real problem.
But back to the original question,
Hi~ It seems that I found a bug on busybox version 1.34.1: In libbb/xfuncs_printf.c:50, malloc twice for archive_handle and archive_hadle->fileheader with 184 and 72 bytes heap space. Back to tar_main function, the two pointers(tar_handle，tar_handle->file_header) hasn't been freed when return.
This isn't a bug. Busybox frequently leaves out the 'free()' operations for anything that is a one-time allocation for the life of the process, because freeing it does nothing more than take up space and time. Memory allocation tools will produce lots of errors when you use them on busybox. It only needs fixed if the memory usage *grows un-bounded* during execution. _______________________________________________ busybox mailing list [email protected] http://lists.busybox.net/mailman/listinfo/busybox
