Hi Chen, On Mon, Feb 03, 2025 at 10:11:14PM +0800, Chen Linxuan wrote: > > > The memory we mmap here is used as the stack of child process we are > > > going to create. > > > Once child process is created, I mean clone(2) return without error, > > > it's OK to munmap(2) memory, > > > as the child process has its own memory space, and that memory is not > > > used in parent process at all. > > > So, whether the clone(2) is success or not, we both need to call > > > munmap(2) to release the memory. > > > > In case of a clone(2) error, exit(3) (called within err(3)) will release > > the memory, right? Why do we need an explicit munmap(2) call? > > > > > > > > If we call munmap(2) after the error handling of clone(2), we will > > > print a error message and then exit > > > before we free those memory. > > > > exit(3) releases all memory, doesn't it? Why would we want to > > explicitly munmap(2) it before printing the error message? > > > > In the code snippet provided as an example for clone(2), I believe we > should strive to write example code in a way that avoids potential > misunderstandings. From the perspective of whether memory is eventually > released, the original program does not technically cause any memory > leak since the parent process exits immediately after completing > clone(2). > > However, I think it's necessary to explicitly perform munmap(2) in > cases where clone(2) fails. The reason is: for readers studying this > documentation, the error handling approach in their actual code might > not be as simple as directly exiting the process. In real-world > scenarios, if the error handling here involves returning error codes > instead of terminating immediately, handling clone(2) error before > calling munmap(2) could become misleading. I believe reporting the error from munmap(2) if there is one, and silencing the clone(2) error, would be similarly confusing. I prefer to have the munmap(2) call after the clone(2) error handling. That's how we do it in most examples. But I like proposal to do correct cleanup in the successful path. Cheers, Alex > By explicitly freeing > resources before error handling, we ensure the example demonstrates > robust practices that remain valid across different error-handling > architectures. > > > > Have a lovely day! > > Alex > > > -- <https://www.alejandro-colomar.es/>
