Used non-sized delete for dynamically sized memory.

Explicitly call non-sized delete on dynamically sized memory for correct behavior under sized-delete.

The code as it stands allocates a chunk of memory of arbitrary size and places an object into it. It stores a pointer to that object and memory into a list telling the compiler that it is a pointer to a char.  When the compiler deletes the objects in the list it thinks that the list contains pointers to chars - not pointers to arbitrarily sized regions of memory.

This is fixing an issue that will reproduces when the following optimization (C++ sized dealocation) is enabled: http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2013/n3536.html

The fix is to explicitly call the non-sized delete operator, and the library code that supports malloc/free/new/delete will figure out the size of the block of memory from the pointer being passed in.

Patch provided by Darryl Gove.

R=mark@chromium.org

Committed: https://chromium.googlesource.com/breakpad/breakpad/+/ebba1800e4bb5ffad3533e6bf01978b578eea91a

[ivanpe, 2016-03-11 01:39:44]

Description was changed from

==========
Used non-sized delete for dynamically sized memory.

Patch provided by Darryl Gove.
==========

to

==========
Used non-sized delete for dynamically sized memory.

Patch provided by Darryl Gove.
==========

[ivanpe, 2016-03-11 01:39:44]

ivanpe@chromium.org changed reviewers:
+ mark@chromium.org

[ivanpe, 2016-03-11 02:40:52]

ivanpe@chromium.org changed reviewers:
+ mmandlis@chromium.org

[Mark Mentovai, 2016-03-11 04:34:23]

LGTM otherwise

https://codereview.chromium.org/1788473002/diff/1/src/processor/static_map_un...
File src/processor/static_map_unittest.cc (right):

https://codereview.chromium.org/1788473002/diff/1/src/processor/static_map_un...
src/processor/static_map_unittest.cc:183: ::operator delete(map_data[i]);
The use of operator new didn’t have ::, why does this?

[Mark Mentovai, 2016-03-11 04:36:24]

Please revise the CL description. The original wasn’t sized either.

[ivanpe, 2016-03-11 23:48:42]

Description was changed from

==========
Used non-sized delete for dynamically sized memory.

Patch provided by Darryl Gove.
==========

to

==========
Use non-sized delete for dynamically sized memory.

Patch provided by Darryl Gove.
==========

[ivanpe, 2016-03-11 23:49:25]

On 2016/03/11 04:36:24, Mark Mentovai wrote:
> Please revise the CL description. The original wasn’t sized either.

I changed the description from "Used" to "Use".

[ivanpe, 2016-03-12 00:27:09]

Description was changed from

==========
Use non-sized delete for dynamically sized memory.

Patch provided by Darryl Gove.
==========

to

==========
Explicitly call non-sized delete on dynamically sized memory for correct
behavior under sized-delete.

The code as it stands allocates a chunk of memory of arbitrary size and places
an object into it. It stores a pointer to that object and memory into a list
telling the compiler that it is a pointer to a char.  When the compiler deletes
the objects in the list it thinks that the list contains pointers to chars - not
pointers to arbitrarily sized regions of memory.

This is fixing an issue that will reproduces when the following optimization
(C++ sized dealocation) is enabled:
http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2013/n3536.html

The fix is to explicitly call the non-sized delete operator, and the library
code that supports malloc/free/new/delete will figure out the size of the block
of memory from the pointer being passed in.

Patch provided by Darryl Gove.
==========

[ivanpe, 2016-03-12 00:30:04]

https://codereview.chromium.org/1788473002/diff/1/src/processor/static_map_un...
File src/processor/static_map_unittest.cc (right):

https://codereview.chromium.org/1788473002/diff/1/src/processor/static_map_un...
src/processor/static_map_unittest.cc:183: ::operator delete(map_data[i]);
On 2016/03/11 04:34:23, Mark Mentovai wrote:
> The use of operator new didn’t have ::, why does this?


The intention is to use the default new operator, but explicitly request the
non-sized delete operator.  I added some more details to the description.

[ivanpe, 2016-03-12 00:37:49]

Description was changed from

==========
Explicitly call non-sized delete on dynamically sized memory for correct
behavior under sized-delete.

The code as it stands allocates a chunk of memory of arbitrary size and places
an object into it. It stores a pointer to that object and memory into a list
telling the compiler that it is a pointer to a char.  When the compiler deletes
the objects in the list it thinks that the list contains pointers to chars - not
pointers to arbitrarily sized regions of memory.

This is fixing an issue that will reproduces when the following optimization
(C++ sized dealocation) is enabled:
http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2013/n3536.html

The fix is to explicitly call the non-sized delete operator, and the library
code that supports malloc/free/new/delete will figure out the size of the block
of memory from the pointer being passed in.

Patch provided by Darryl Gove.
==========

to

==========
Explicitly call non-sized delete on dynamically sized memory for correct
behavior under sized-delete.

The code as it stands allocates a chunk of memory of arbitrary size and places
an object into it. It stores a pointer to that object and memory into a list
telling the compiler that it is a pointer to a char.  When the compiler deletes
the objects in the list it thinks that the list contains pointers to chars - not
pointers to arbitrarily sized regions of memory.

This is fixing an issue that will reproduces when the following optimization
(C++ sized dealocation) is enabled:
http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2013/n3536.html

The fix is to explicitly call the non-sized delete operator, and the library
code that supports malloc/free/new/delete will figure out the size of the block
of memory from the pointer being passed in.

Patch provided by Darryl Gove.

R=mark@chromium.org

Committed:
https://chromium.googlesource.com/breakpad/breakpad/+/ebba1800e4bb5ffad3533e6...
==========

[ivanpe, 2016-03-12 00:37:51]

Committed patchset #1 (id:1) manually as
ebba1800e4bb5ffad3533e6bf01978b578eea91a (presubmit successful).