[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [libunwind] sos_alloc()
From: |
David Mosberger |
Subject: |
Re: [libunwind] sos_alloc() |
Date: |
Fri, 26 Mar 2004 14:13:16 -0800 |
>>>>> On Fri, 26 Mar 2004 15:45:30 -0600 (CST), Todd L Miller <address@hidden>
>>>>> said:
Todd> Those two fixes didn't seem to help, but I've been
Todd> hacking on the stock 0.96 release of libunwind, so I may be
Todd> missing other fixes. Is there a (reasonable) way of getting
Todd> the current libunwind sources without using BK? (Maybe
Todd> convert the BK changesets from the 0.96 release to a patch?)
If you know your way around Debian, I believe Matthieu is providing
Debian packages for the latest BK snapshots. Look for "snap" on
this page:
http://www.esiee.fr/~delahaym/libunwind/
Is it that you don't _want_ to use bitkeeper or is it just that
you're not familiar with it? If it's the latter, all you should
have to do is:
bk clone bk://unwind.bkbits.net/libunwind/
cd libunwind
bk -r get -S
and then you'll have the latest sources.
Todd> I've been working around the problem by doubling the
Todd> sos_alloc array size (up to 64K now). I inserted an
Todd> fprintf(stderr...) where mempool.c and tables-ia64.c call
Todd> sos_alloc() [they're the only two], and only got this for
Todd> tables-ia64. I got 293 hits there, each of 112 bytes which
Todd> would 32816, just larger than the 32768 that I'd had before
Todd> doubling the pool again.
Hmmh, that's odd. sos_alloc() only gets called when you're out of
memory or for obtaining the kernel's unwind table (which happens only
once). There were some bugs in that area at one point, but I thought
0.96 was OK. In any case, since you're doing bleeding-edge kind of
stuff, it probably is a good idea to track the latest source code.
Todd> Is there a reason for tables-ia64 (_Uia64_get_kernel_table(),
Todd> specifically) to use sos_alloc() instead of, e.g., malloc()?
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! ;-)
--david