Em Tue, Mar 18, 2014 at 08:05:33AM -0700, Andi Kleen escreveu: > > Humm, this unconditionally replaces it with an alternative that limits > > the buffer to a fixed size :-\ > > Better than corrupting memory.
Yes, it is better than corrupting memory, use the less ugly, good point. > I guess you could use two passes to avoid the limit, but it would surprise me > if anything in perf needs more than 1K of printf. One issue > with doing two passes is that I wasn't sure the snprintf return The return of snprintf is crazy, that is why we use scnprintf. > value would work properly on all libcs (e.g. the weirdo one Android uses) > > > > > Do you recall at least one of those old glibc version/release number? > glibc-2.13-2.x86_64 (FC14) > > A reproducer? So that I can try to reproduce it here and try to polish > > this a bit more... > > I saw it with perf report --branch-history in TUI mode and then pressing > e. But even running valgrind in stdio mode showed some corruption. > Without the patch also using some of the --call-graph options segfaulted. Thanks for the data points, - Arnaldo -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [email protected] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
