tor callgrinds

Christopher Layne clayne at
Sat Feb 17 03:59:11 UTC 2007

On Fri, Feb 16, 2007 at 10:12:20PM -0500, Watson Ladd wrote:
> > Without the visualizer itself it can be difficult to find the context just
> > by looking at a snapshot.
> > 
> > It's mainly being called from _tor_strndup(), from what I can see, which
> > specifically notes:
> > 
> > /** Allocate and return a new string containing the first <b>n</b>
> >  * characters of <b>s</b>.  If <b>s</b> is longer than <b>n</b>
> >  * characters, only the first <b>n</b> are copied.  The result is
> >  * always NUL-terminated.  (Like strndup(s,n), but never returns
> >  * NULL.)
> >  */
> 1: So what happens when malloc returns NULL?

That would normally be a problem. However the call is not to malloc(),
it is to _tor_malloc().

Within _tor_malloc():
  if (!result) {
    log_err(LD_MM,"Out of memory. Dying.");
    /* XXX if these functions die within a worker process, they won't
     * call spawn_exit */

It's very common to have malloc() wrappers in any kind of utility code.

> 2: Won't strlcpy run in time proportional to n? strncpy can't be much
> faster as both functions need to loop from 0..n, load the character and
> check if its null, and then copy it. The big difference is strncpy keeps
> on going.

Right, you would think so - however that's in a non-native entirely portable
strncpy(). Almost all the common str*(), mem*() stdlib functions are
implemented in assembler on Linux and other modern OSes.

BTW: OpenSolaris has a strlcpy.s, but usage would be subject to their
license terms (which I haven't done any research on).

Might be a moot point if the glibc one is also in x86 asm.


More information about the tor-dev mailing list