libunwind-devel
[Top][All Lists]
Advanced

[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


reply via email to

[Prev in Thread] Current Thread [Next in Thread]