re2: Initialize sparse_to_dense_ on initial allocation under Valgrind.

re2: Initialize sparse_to_dense_ on initial allocation under Valgrind.

This change moves logic to appease Valgrind by initializing |a| out of
the sparse_to_dense_ NULL check so that it is also run when the default
SparseArray() constructor was used, leaving sparse_to_dense_ NULL before
the first call to resize.

This was caught by Valgrind, Dr. Memory and MSan.

BUG=568373
R=thakis@chromium.org

Committed: https://crrev.com/7e7706ee201acbd7e4784fbd6f8821f6647b624c
Cr-Commit-Position: refs/heads/master@{#364292}

[Reilly Grant (use Gerrit), 2015-12-10 00:55:05]

Please take a look at this patch.

[Nico, 2015-12-10 01:05:39]

There's no bug link with a valgrind stack explaining what exactly's going on
– but if this is just an unitialized read report due to compiler optimizations
(https://code.google.com/p/chromium/issues/detail?id=399852#c6) we usually
suppress these instead of landing downstream patches to third-party code

[Reilly Grant (use Gerrit), 2015-12-10 01:12:57]

Description was changed from

==========
re2: Initialize sparse_to_dense_ on initial allocation under Valgrind.

This change moves logic to appease Valgrind by initializing |a| out of
the sparse_to_dense_ NULL check so that it is also run when the default
SparseArray() constructor was used, leaving sparse_to_dense_ NULL before
the first call to resize.

R=thakis@chromium.org
==========

to

==========
re2: Initialize sparse_to_dense_ on initial allocation under Valgrind.

This change moves logic to appease Valgrind by initializing |a| out of
the sparse_to_dense_ NULL check so that it is also run when the default
SparseArray() constructor was used, leaving sparse_to_dense_ NULL before
the first call to resize.

BUG=568373
R=thakis@chromium.org
==========

[Reilly Grant (use Gerrit), 2015-12-10 01:14:52]

On 2015/12/10 01:05:39, Nico wrote:
> There's no bug link with a valgrind stack explaining what exactly's going on
> – but if this is just an unitialized read report due to compiler
optimizations
> (https://code.google.com/p/chromium/issues/detail?id=399852#c6) we usually
> suppress these instead of landing downstream patches to third-party code

I've filed a bug with the MSan stack trace. RE2 has code to silence the Valgrind
warnings (also used for MSan, which doesn't support suppressions). It just had a
bug. This patch fixes it and can certainly be submitted upstream.

[Nico, 2015-12-10 01:28:54]

lgtm, please say "msan" somewhere in the cl description, and please send this
upstream too.

[Reilly Grant (use Gerrit), 2015-12-10 01:43:42]

Description was changed from

==========
re2: Initialize sparse_to_dense_ on initial allocation under Valgrind.

This change moves logic to appease Valgrind by initializing |a| out of
the sparse_to_dense_ NULL check so that it is also run when the default
SparseArray() constructor was used, leaving sparse_to_dense_ NULL before
the first call to resize.

BUG=568373
R=thakis@chromium.org
==========

to

==========
re2: Initialize sparse_to_dense_ on initial allocation under Valgrind.

This change moves logic to appease Valgrind by initializing |a| out of
the sparse_to_dense_ NULL check so that it is also run when the default
SparseArray() constructor was used, leaving sparse_to_dense_ NULL before
the first call to resize.

This was caught by Valgrind, Dr. Memory and MSan.

BUG=568373
R=thakis@chromium.org
==========

[Reilly Grant (use Gerrit), 2015-12-10 01:43:59]

The CQ bit was checked by reillyg@chromium.org

[commit-bot: I haz the power, 2015-12-10 01:44:23]

CQ is trying da patch. Follow status at
 https://chromium-cq-status.appspot.com/patch-status/1509953005/1
View timeline at
 https://chromium-cq-status.appspot.com/patch-timeline/1509953005/1

[commit-bot: I haz the power, 2015-12-10 06:05:13]

Description was changed from

==========
re2: Initialize sparse_to_dense_ on initial allocation under Valgrind.

This change moves logic to appease Valgrind by initializing |a| out of
the sparse_to_dense_ NULL check so that it is also run when the default
SparseArray() constructor was used, leaving sparse_to_dense_ NULL before
the first call to resize.

This was caught by Valgrind, Dr. Memory and MSan.

BUG=568373
R=thakis@chromium.org
==========

to

==========
re2: Initialize sparse_to_dense_ on initial allocation under Valgrind.

This change moves logic to appease Valgrind by initializing |a| out of
the sparse_to_dense_ NULL check so that it is also run when the default
SparseArray() constructor was used, leaving sparse_to_dense_ NULL before
the first call to resize.

This was caught by Valgrind, Dr. Memory and MSan.

BUG=568373
R=thakis@chromium.org
==========

[commit-bot: I haz the power, 2015-12-10 06:05:14]

Committed patchset #1 (id:1)

[commit-bot: I haz the power, 2015-12-10 06:06:11]

Description was changed from

==========
re2: Initialize sparse_to_dense_ on initial allocation under Valgrind.

This change moves logic to appease Valgrind by initializing |a| out of
the sparse_to_dense_ NULL check so that it is also run when the default
SparseArray() constructor was used, leaving sparse_to_dense_ NULL before
the first call to resize.

This was caught by Valgrind, Dr. Memory and MSan.

BUG=568373
R=thakis@chromium.org
==========

to

==========
re2: Initialize sparse_to_dense_ on initial allocation under Valgrind.

This change moves logic to appease Valgrind by initializing |a| out of
the sparse_to_dense_ NULL check so that it is also run when the default
SparseArray() constructor was used, leaving sparse_to_dense_ NULL before
the first call to resize.

This was caught by Valgrind, Dr. Memory and MSan.

BUG=568373
R=thakis@chromium.org

Committed: https://crrev.com/7e7706ee201acbd7e4784fbd6f8821f6647b624c
Cr-Commit-Position: refs/heads/master@{#364292}
==========

[commit-bot: I haz the power, 2015-12-10 06:06:14]

Patchset 1 (id:??) landed as
https://crrev.com/7e7706ee201acbd7e4784fbd6f8821f6647b624c
Cr-Commit-Position: refs/heads/master@{#364292}