http://bugs.meego.com/show_bug.cgi?id=1007
--- Comment #5 from yongsheng <yongsheng.zhu(a)intel.com> 2010-05-24 22:47:18 PDT ---
(In reply to comment #3)
> What does --track-origins=yes say, and what is the more complete
stack back
> trace? How do I reproduce this?
1. how to reproduce:
env GLIBCXX_FORCE_NEW=1 G_SLICE=always-malloc G_DEBUG=gc-friendly valgrind
--suppressions=/home/yzhu17/views/syncevolution/test/sys.supp
--suppressions=/home/yzhu17/views/syncevolution/test/evo.supp --num-callers=30
--leak-check=yes --trace-children=no --quiet --track-origins=yes
--gen-suppressions=all --log-file=valgrind.out client-test
N7SyncEvo7LCSTestE::lcs
2. please open the link to see detail:
http://zys.sh.intel.com/valgrind.txt For
this issue, I find the root cause: read over the size of the buffer.
In lcs.h line 196:
class accessor {
static C cost(const T &b, ssize_t start, size_t end) {
return b[end].second - (start == -1 ? 0 : b[start].second);
}
}
for(int j = 0; j <=b.size(); j++)
196 C cost_left = sub[i][j-1].cost += access.cost(b, j-1, j);
access.cost(b, j-1, j) will read b[j] and j may equal the size of b, so this
will cause reading an invalid value
--
Configure bugmail:
http://bugs.meego.com/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are watching someone on the CC list of the bug.