[Home]

Summary:ASTERISK-27243: contrib: valgrind.supp doesn't suppress what it's supposed to due to invalid syntax
Reporter:Richard Kenner (kenner)Labels:
Date Opened:2017-09-01 18:30:57Date Closed:2020-01-07 09:57:44.000-0600
Priority:TrivialRegression?
Status:Closed/CompleteComponents:Contrib/General
Versions:14.6.0 Frequency of
Occurrence
Related
Issues:
Environment:CentOS 7Attachments:
Description:contrib/valgrind.supp appears to be trying to suppress this error:

{noformat}
==11012== Conditional jump or move depends on uninitialised value(s)
==11012==    at 0x28217588: speex_decode_int (in /usr/lib64/libspeex.so.1.5.0)
==11012==    by 0x2800AFDB: speextolin_framein (codec_speex.c:229)
==11012==    by 0x608A45: framein (translate.c:423)
==11012==    by 0x609628: generate_computational_cost (translate.c:678)
==11012==    by 0x60B08F: __ast_register_translator (translate.c:1223)
==11012==    by 0x2800C13F: load_module (codec_speex.c:626)
==11012==    by 0x544755: start_resource (loader.c:988)
==11012==    by 0x54537A: load_resource_list (loader.c:1240)
==11012==    by 0x545A71: load_modules (loader.c:1375)
==11012==    by 0x45DD48: asterisk_daemon (asterisk.c:4647)
==11012==    by 0x45D299: main (asterisk.c:4396)
{noformat}

but it actually doesn't and the error is still reported.
Comments:By: Asterisk Team (asteriskteam) 2017-09-01 18:30:59.143-0500

Thanks for creating a report! The issue has entered the triage process. That means the issue will wait in this status until a Bug Marshal has an opportunity to review the issue. Once the issue has been reviewed you will receive comments regarding the next steps towards resolution.

A good first step is for you to review the [Asterisk Issue Guidelines|https://wiki.asterisk.org/wiki/display/AST/Asterisk+Issue+Guidelines] if you haven't already. The guidelines detail what is expected from an Asterisk issue report.

Then, if you are submitting a patch, please review the [Patch Contribution Process|https://wiki.asterisk.org/wiki/display/AST/Patch+Contribution+Process].
By: Rusty Newton (rnewton) 2017-09-14 10:27:39.523-0500

Looks like you can use the "--gen-suppressions=yes"[1] option to generate a suppression for the error. Then you can compare this to the entry already in the suppression file. Then, you can copy that to the suppression file if you need for a workaround.

Perhaps this is a real error and not what was originally intended to be suppressed with the current suppression file. Have you run into any issues with libspeex?

[1]: http://valgrind.org/docs/manual/manual-core.html#manual-core.options
By: Richard Kenner (kenner) 2017-09-14 10:32:51.795-0500

It sure *looks* like it's trying to supress that error:

{noformat}
{
  speex_decode
  Memcheck:Cond
  fun:speex_decode_int
  fun:...
}
{noformat}

It occurs during initialization.  I haven't seen any reason to believe there's a real problem here.  When I get a chance (which likely won't be until the weekend), I'll try the --gen-suppressions=yes option and see how the entry differs from what's above.
By: Richard Kenner (kenner) 2017-09-14 17:37:20.487-0500

I got a chance to do this today, after all.  What valgrind generated appeared to me to be the same as was in the input file, so it's wierd:

{noformat}
{
  <insert_a_suppression_name_here>
  Memcheck:Cond
  fun:speex_decode_int
  fun:speextolin_framein
  fun:framein
  fun:generate_computational_cost
  fun:__ast_register_translator
  fun:load_module
  fun:start_resource
  fun:load_resource_list
  fun:load_modules
  fun:asterisk_daemon
  fun:main
}
{noformat}

By: Rusty Newton (rnewton) 2017-09-19 14:54:56.940-0500

Huh. Did you try putting that in the suppression file to see if that successfully suppressed?
By: Richard Kenner (kenner) 2017-09-19 15:02:59.255-0500

No, but I guess I should have. ;-)

Hopefully, this weekend.
By: Rusty Newton (rnewton) 2017-09-19 15:07:45.829-0500

:)

It'll be interesting if those entries behave differently!
By: Richard Kenner (kenner) 2017-09-23 14:50:30.633-0500

They do, and I found the problem.  Apparently, the correct syntax for valgrind.supp is just "...", not "fun: ...".

By: Rusty Newton (rnewton) 2017-09-26 18:50:30.444-0500

Awesome! Looks like an easy patch then. I'm going to open it up, so you or any other community member can contribute a patch and tackle it at your leisure.
By: Friendly Automation (friendly-automation) 2020-01-07 09:57:45.962-0600

Change 13538 merged by George Joseph:
contrib/valgrind: Fix use of frame-level suppression

[https://gerrit.asterisk.org/c/asterisk/+/13538|https://gerrit.asterisk.org/c/asterisk/+/13538]
By: Friendly Automation (friendly-automation) 2020-01-07 09:58:36.847-0600

Change 13536 merged by George Joseph:
contrib/valgrind: Fix use of frame-level suppression

[https://gerrit.asterisk.org/c/asterisk/+/13536|https://gerrit.asterisk.org/c/asterisk/+/13536]
By: Friendly Automation (friendly-automation) 2020-01-07 09:59:37.478-0600

Change 13453 merged by George Joseph:
contrib/valgrind: Fix use of frame-level suppression

[https://gerrit.asterisk.org/c/asterisk/+/13453|https://gerrit.asterisk.org/c/asterisk/+/13453]
By: Friendly Automation (friendly-automation) 2020-01-07 10:00:34.526-0600

Change 13537 merged by George Joseph:
contrib/valgrind: Fix use of frame-level suppression

[https://gerrit.asterisk.org/c/asterisk/+/13537|https://gerrit.asterisk.org/c/asterisk/+/13537]