tor callgrinds

[Christopher Layne]

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 */
    exit(1);
  }

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).

http://src.opensolaris.org/source/xref/onnv/onnv-gate/usr/src/lib/libc/sparcv9/gen/strlcpy.s

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

-cl