[PATCH] fix strace -s N handling

[Denys Vlasenko]

On Thu, 2008-11-06 at 14:24 +0300, Dmitry V. Levin wrote:
> On Wed, Nov 05, 2008 at 07:18:45PM +0100, Denys Vlasenko wrote:
> > On Wed, 2008-11-05 at 15:16 +0100, Denys Vlasenko wrote:
> > > Before this patch, -s N shows N+1 chars in strings.
> > > More annoyingly, it shows this for shorter strings:
> > > 
> > > write(1, "hi\n"..., 3) = 3
> > > 
> > > After patch:
> > > 
> > > write(1, "hi\n", 3) = 3
> > > 
> > > Patch author is Jeff Bastian jbastian at redhat.com
> > > 
> > > Patch is below. Please apply.
> > 
> > It appears that the bug this patch fixes causes buffer overruns
> > and corrupts memory since we malloc just enough space for N chars
> > + NUL but then try to stuff N+1 chars + NUL there.
> > 
> > See https://bugzilla.redhat.com/show_bug.cgi?id=466877
> 
> This bug is not available for public access.

Hmmm yes, whoever created it was probably feeling too paranoid...

But the bug itself is not secret at all, it's just "strace -Tdf firefox"
crashing...

This is what I wrote in that bug's comment:

===========================
Non-deterministic, happens in about half of runs.

strace -f firefox seems to be enough. Adding -T and -d might make it
happen more frequently, I didn't perform statistical analysis. :)

Vanilla (built from source tarball locally) strace-4.5.17 exhibits it
too, although it does not print glibc malloc debug assertion, it just
segfaults. Understandable, since it seems to be a case of memory
corruption.
============================

As it turns out, firefox crashes it most easily just because it has
tons of strings in the strace and many threads, which probably makes
much easier to corrupt malloc space by trashing a few bytes just beyond
allocated space.
--
vda