Re: [libunwind] sos_alloc()

[Todd L Miller]

> Yes.  libunwind must work even when the system is out of memory.
> Consider the case where you want to throw an exception (or print a
> backtrace) after getting a SIGSEGV because you're out of memory.
> Trust me, I don't do memory allocators for fun! ;-)

        Ah.  But, as I mentioned earlier, libunwind never (seems to) free
it (the 112 bytes for the kernel table).  I believe what's going on is
that the kernel table is being fetched every time I call
unw_is_signal_frame().  (Once per frame per stackwalk.)  While I'm
guessing this would be cached under normal circumstance, I'm creating the
address space (and calling _UPT_create())  every time* I do a stackwalk,
and _UPT_destroy() and unw_destroy_addr_space() don't free the
sos_alloc()'d memory for the kernel unwind table.

- Todd Miller

* My program can want to unwind the stacks in more than one remote process
concurrently.  I was having problems when I tried to cache unwind cursors
in this situation, and ended up with the current exceedingly brute-force
solution.  _Should_ libunwind work with multiple remote processes?  (That
is, are there internal data structures not associated with the address
space and cursor?)  This hack is probably what causes the 293
sos_alloc()s.  If, in fact, I must tear down and rebuild libunwind every
time I switch between remote processes, I need some way to free
sos_alloc()d memory, or else libunwind will always run out of memory.