If mmap fails, be sure to close the maps file before returning an error.
Signed-off-by: Zachary T Welch <zwelch@codesourcery.com>
Signed-off-by: Ken Werner <ken.werner@linaro.org>
Currently, libunwind allocates several PATH_MAX entries on stack, while
trying to find a binary via /proc/.../maps.
However stack space may be at premium (especially when sigaltstack is used),
and PATH_MAX on Linux is 4096, while SIGSTKSZ is only 8192 on x86.
Attached patch eliminates multiple PATH_MAX stack allocations, and simplifies
code in maps_next, at the cost of being unable to do anything if we can't
mmap one page. It appears to me that under such low-memory conditions,
libunwind will fail shortly elsewhere anyway.
This patch also disables more of debug_frame-handling code when
CONFIG_DEBUG_FRAME is undefined.
Tested on Linux/x86_64 with and without CONFIG_DEBUG_FRAME, no regressions.
(maps_next): After reading less than a full buffer of data, copy
remaining data to the top of the buffer so as to maintain the
invariant that all data between mi->buf and mi->buf_end is valid.
This avoids maps_next() parsing uninitialized data.
(maps_init): Try to mmap() a one-page buffer and, if successful,
initialize the new map_iterator members based on it.
(maps_next): If the one-page buffer is available, use it to read
/proc/PID/maps. This avoids expensive lseek() calls which,
in the case of /proc lead to T(n) = O(n^2) behavior.
(Logical change 1.208)
