[PATCH v3] Print absolute paths in printpathn when -yy is used

[Dmitry V. Levin]

On Mon, Jun 16, 2014 at 10:47:05PM -0400, Mike Frysinger wrote:
> On Sun 15 Jun 2014 09:14:05 zubin.mithra at gmail.com wrote:
> > From: Zubin Mithra <zubin.mithra at gmail.com>
[...]
> > +	ssize_t n;
> > +
> > +	snprintf(linkpath, link_size, "/proc/%u/cwd", tcp->pid);
> > +	n = readlink(linkpath, cwd, MAXPATHLEN);
> 
> 
> anytime you start using magic constant lengths for paths, you know you're 
> probably doing something wrong.  you have to remember that some systems don't 
> have a max path length restriction so these constants won't even be defined.

strace already uses MAXPATHLEN, e.g. in printpath(), so do we really want
to support /proc/pid/cwd symlinks that are longer than MAXPATHLEN?
If we do, then it should be implemented via realloc loop.  
If not, then we should handle this very unlikely case of
readlink(MAXPATHLEN+1) returning a value greater than MAXPATHLEN,
e.g. by treating it like readlink error.

> i would also highlight that some systems (really just nommu) really do
> not want large buffer stacks because the stack size is fixed.  by
> putting large values there, you can easily blow it (which this code is
> doing).  if this particular func matters to performance, we can use a
> cached malloc buffer (that you can realloc() to increase over time).
> -mike

printpathn() already does alloca(MAXPATHLEN * 4), so this case does not
introduce something new.  If this is too big for the stack, we could use
a static buffer, or indeed a cached malloc buffer if we want to lift this
MAXPATHLEN limit.


-- 
ldv
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 181 bytes
Desc: not available
URL: <http://lists.strace.io/pipermail/strace-devel/attachments/20140618/1ce950e3/attachment.bin>