https://bugs.kde.org/show_bug.cgi?id=417075
--- Comment #4 from Philippe Waroquiers <philippe.waroqui...@skynet.be> ---
(In reply to Leonid Yuriev from comment #3)
> > What does `valgrind --gen-suppressions=all ...` show ?
> {
> <insert_a_suppression_name_here>
> Memcheck:Param
> pwritev(vector[0])
> fun:pwritev
> fun:mdbx_pwritev
> fun:mdbx_flush_iov
> fun:mdbx_page_flush
> fun:mdbx_txn_commit
> fun:_ZN8testcase16breakable_commitEv
> fun:_ZN8testcase39db_open__begin__table_create_open_cleanERj
> fun:_ZN15testcase_nested5setupEv
> fun:_Z12test_executeRK12actor_config
> fun:_Z16osal_actor_startRK12actor_configRi
> fun:main
> }
>
> {
> <insert_a_suppression_name_here>
> Memcheck:Param
> pwritev(vector[1])
>
> ...
> pwritev(vector[2])
> ...
> pwritev(vector[3]) and so on.
>
>
> > Does it suppress if you use the suppression exactly as generated by
> > valgrind ?
> Suppressions works for an every explicitly `vector[N]`, but not for the
> `vector[...]`.
As I understand, you are expecting vector[...] in the line following
Memcheck:Param to match vector[1] or vector[2] or ...
There is no such logic. This part of the error must match exactly.
Your suppression entry was working with 3.13 because in 3.13, the error
was generated with vector[...]
Such errors for pwritev was changed from producing vector[...]
to vector[0], vector[1], etc as part of the commit:
commit b0861063a8d2a55bb7423e90d26806bab0f78a12
Author: Alexandra Hájková <ahajk...@redhat.com>
AuthorDate: Tue Jun 4 13:47:14 2019 +0200
Commit: Mark Wielaard <m...@klomp.org>
CommitDate: Wed Jul 3 00:19:16 2019 +0200
As far as I can see, the fact that the new error message after this commit
contains a varying offset between brackets is what causes the problem:
this looks to me to be a backward incompatible change (as shown by your
supp that stopped working between 3.13 and 3.15) and does not match
the 'idea' of error parameters. Here are some comments extracted from
the description of void VG_(maybe_record_error):
Note that `ekind' and `s' are also used to generate a suppression.
`s' should therefore not contain data depending on the specific
execution (such as addresses, values) but should rather contain
e.g. a system call parameter symbolic name.
(where 's' is this vector[1] etc string).
Wondering how to fix this ...
If we go back to the behaviour before 3.15, we break the suppression
entries working for 3.15, and if we do not go back, we break the suppression
entries working for 3.14 and before.
--
You are receiving this mail because:
You are watching all bug changes.
