[Fix] add to_arena() when only the first argument is a matrix<var> for elt_multiply

[SteveBronder]

Summary

Just a quick bug fix, I forgot to wrap the non-var matrix in to_arena() in elt_multiply

Tests

No new tests, would there be some way to auto catch these sort of things?

Side Effects

Release notes

Checklist

• Math issue #(issue number)

• Copyright holder: Steve Bronder

  The copyright holder is typically you or your assignee, such as a university or company. By submitting this pull request, the copyright holder is agreeing to the license the submitted work under the following licenses:
  - Code: BSD 3-clause (https://opensource.org/licenses/BSD-3-Clause)
  - Documentation: CC-BY 4.0 (https://creativecommons.org/licenses/by/4.0/)

• the basic tests are passing

  • unit tests pass (to run, use: ./runTests.py test/unit)
  • header checks pass, (make test-headers)
  • dependencies checks pass, (make test-math-dependencies)
  • docs build, (make doxygen)
  • code passes the built in C++ standards checks (make cpplint)

• the code is written in idiomatic C++ and changes are documented in the doxygen

• the new changes are tested

[stan-buildbot]

---

Name	Old Result	New Result	Ratio	Performance change( 1 - new / old )
gp_pois_regr/gp_pois_regr.stan	3.15	3.16	1.0	-0.33% slower
low_dim_corr_gauss/low_dim_corr_gauss.stan	0.02	0.02	0.99	-0.63% slower
eight_schools/eight_schools.stan	0.12	0.12	0.98	-2.23% slower
gp_regr/gp_regr.stan	0.18	0.18	1.0	-0.36% slower
irt_2pl/irt_2pl.stan	5.69	5.66	1.0	0.41% faster
performance.compilation	90.7	89.8	1.01	1.0% faster
low_dim_gauss_mix_collapse/low_dim_gauss_mix_collapse.stan	9.06	9.05	1.0	0.16% faster
pkpd/one_comp_mm_elim_abs.stan	29.15	28.88	1.01	0.93% faster
sir/sir.stan	128.5	124.79	1.03	2.89% faster
gp_regr/gen_gp_data.stan	0.04	0.05	0.97	-3.21% slower
low_dim_gauss_mix/low_dim_gauss_mix.stan	3.16	3.17	1.0	-0.04% slower
pkpd/sim_one_comp_mm_elim_abs.stan	0.38	0.4	0.95	-5.13% slower
arK/arK.stan	2.56	2.55	1.0	0.23% faster
arma/arma.stan	0.74	0.74	1.01	0.54% faster
garch/garch.stan	0.66	0.66	1.0	0.27% faster
Mean result: 0.996683884731

---

Jenkins Console Log
Blue Ocean
Commit hash: a0d9630

---

Machine information

ProductName: Mac OS X ProductVersion: 10.11.6 BuildVersion: 15G22010

CPU:
Intel(R) Xeon(R) CPU E5-1680 v2 @ 3.00GHz

G++:
Configured with: --prefix=/Applications/Xcode.app/Contents/Developer/usr --with-gxx-include-dir=/usr/include/c++/4.2.1
Apple LLVM version 7.0.2 (clang-700.1.81)
Target: x86_64-apple-darwin15.6.0
Thread model: posix

Clang:
Apple LLVM version 7.0.2 (clang-700.1.81)
Target: x86_64-apple-darwin15.6.0
Thread model: posix

[bbbales2]

Hmm there really isn't a way to write a test for this sorta thing is there.

[bbbales2]

I approve. Leaving this open if you (@SteveBronder) wanted to talk about how we could go about testing this.

If you want to merge and talk about that somewhere else, that's fine with me.

[bbbales2]

I guess how did you discover it? I assume something segfaulted? Can we turn on the address sanitizer for our tests? That's more aggressive about checking memory I thought.

[SteveBronder]

I guess how did you discover it? I assume something segfaulted? Can we turn on the address sanitizer for our tests? That's more aggressive about checking memory I thought.

Yeah my computer crashed and I was like, "Well that's not good". I think using the address sanitizer is a good idea here. We would need to make sure all the tests call recover_memory() correctly and it should be able to check if anything is left dangling that should not be

[bbbales2]

Cool. If you don't get around to testing the address sanitizer today, then document this as an issue I suppose. Don't wanna forget about this one cause it's sneaky.

[rok-cesnovar]

We talked about something similar with Tadej. Would running such tests weekly + valgrind tests work? Can make an issue and set that up.

[bbbales2]

Well if the address sanitizer can catch these errors then could we just turn it on with the unit tests? Or are the unit tests too messy to do that? Or is the sanitizer too slow?

I definitely wouldn't want to run valgrind on the unit tests on commit. It would take a week to finish.

[rok-cesnovar]

I would definitely run that with unit tests. I can imagine the sanitizer also takes some additional time? If its not much then we can just add it to commit tests yeah.

I definitely wouldn't want to run valgrind on the unit tests on commit. It would take a week to finish.

Yep.