Re: [libunwind] sos_alloc()

[Todd L Miller]

> Yes, the kernel-table is read only once (not per address-space).

        Then something is terribly wrong, because, as I said earlier, I
can see space for it being allocated 293 times.

> Oh, you're calling unw_is_signal_frame()?  That would be the _other_
> leak I was referring to (well, I think I did).  Try this:

        You did, and I coded an essentially identical patch, to no avail.
The resource that's running out is _not_ normal heap memory; it's space
in the array that sos_alloc() uses.

        get_unwind_info() checks ui->ktab.start_ip to see if it needs to
fetch the kernel table, and needs to, every time I call _UPT_create()*,
because it zeroes the UPT_info structure, including the ktab, which
libunwind (with good reason) does not cache internally. This means that
every instantiation of the remote unwinder leaks 112 bytes of SOS memory
(if is_unwind_frame() is ever called).

        This may well be a concious design choice.  (That it's not worth
the trouble to support clients that instantiate the remote unwinder more
than X times.)

        I want, however, to make sure that the problem I see is
understood, and the responses I've been getting, while cogent and useful,
haven't convinced me of that.  My apologies if I've being obtuse.

> Yes.  There should be no problem creating multiple concurrent
> address-spaces (and destroying them when you're done with them).

        That's good news, and I'll give it a try shortly; certainly, it
will put the problem off for a good long time.

- Todd Miller

* Which I do, because of how broken my code is right now, just shy of 300
times.