fix segfault for EmbeddingBag on CPU slow path when include_last_offset is true #90358
Conversation
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
…et is true [ghstack-poisoned]
🔗 Helpful Links🧪 See artifacts and rendered test results at hud.pytorch.org/pr/90358
Note: Links to docs will display an error until the docs builds have been completed. ✅ No FailuresAs of commit b6e030e: This comment was automatically generated by Dr. CI and updates every 15 minutes. |
mingfeima
added
topic: not user facing
mingfeima
requested review from
albanD,
ezyang,
jbschlosser,
kurtamohler and
malfet
ezyang
reviewed
Dec 12, 2022
ezyang
reviewed
Dec 12, 2022
…e_last_offset is true" This PR is to fix the segfault reported at #89677, this is a `double free` issue caused by `invalid read`. The reported issue broke at slow path for `EmbeddingBag` on float32, at [EmbeddingBag.cpp#L451](https://github.com/pytorch/pytorch/blob/master/aten/src/ATen/native/EmbeddingBag.cpp#L451) Root cause is that `add_indices` has index which exceeds range of `output_data`, for the reported case. The offsets are given as ``` {0, 6, 12, 15, 25, 32, 40, 42, 46, 53, 53} ``` The `indices` has 55 elements and `offsets[-1] != indices.size(0)`. When `include_last_offset` is true, the `output` will be in the shape of {offsets.size(0) - 1, weight.sizes()[1]}, which will be {10, 5}. Originally, `add_indices` will be (i re-arange the 1D tensor by rows, so here 10 rows in total) ``` ### this is 55 elements 0 0 0 0 0 0 1 1 1 1 1 1 2 2 2 3 3 3 3 3 3 3 3 3 3 4 4 4 4 4 4 4 5 5 5 5 5 5 5 5 6 6 7 7 7 7 8 8 8 8 8 8 8 10 10 ``` The last row has index of 10 which is out of range of output tensor whose size is [10, 5]. The reason is `make_offset2bag` at [EmbeddingBag.cpp#L66](https://github.com/pytorch/pytorch/blob/master/aten/src/ATen/native/EmbeddingBag.cpp#L66) would give the following `offset2bag`: ``` ### this is 55 + 1 elements: 0 0 0 0 0 0 1 0 0 0 0 0 1 0 0 1 0 0 0 0 0 0 0 0 0 1 0 0 0 0 0 0 1 0 0 0 0 0 0 0 1 0 1 0 0 0 1 0 0 0 0 0 0 2 0 0 ``` Notice for index 53, it is added twice. The fix is ignore the last index from `offsets` when `include_last_offset` is true, also this behavior aligns with CUDA, quote from #57208 (comment) cc jgong5 @XiaobingSuper sanchitintel ashokei jingxu10 [ghstack-poisoned]
…e_last_offset is true" This PR is to fix the segfault reported at #89677, this is a `double free` issue caused by `invalid read`. The reported issue broke at slow path for `EmbeddingBag` on float32, at [EmbeddingBag.cpp#L451](https://github.com/pytorch/pytorch/blob/master/aten/src/ATen/native/EmbeddingBag.cpp#L451) Root cause is that `add_indices` has index which exceeds range of `output_data`, for the reported case. The offsets are given as ``` {0, 6, 12, 15, 25, 32, 40, 42, 46, 53, 53} ``` The `indices` has 55 elements and `offsets[-1] != indices.size(0)`. When `include_last_offset` is true, the `output` will be in the shape of {offsets.size(0) - 1, weight.sizes()[1]}, which will be {10, 5}. Originally, `add_indices` will be (i re-arange the 1D tensor by rows, so here 10 rows in total) ``` ### this is 55 elements 0 0 0 0 0 0 1 1 1 1 1 1 2 2 2 3 3 3 3 3 3 3 3 3 3 4 4 4 4 4 4 4 5 5 5 5 5 5 5 5 6 6 7 7 7 7 8 8 8 8 8 8 8 10 10 ``` The last row has index of 10 which is out of range of output tensor whose size is [10, 5]. The reason is `make_offset2bag` at [EmbeddingBag.cpp#L66](https://github.com/pytorch/pytorch/blob/master/aten/src/ATen/native/EmbeddingBag.cpp#L66) would give the following `offset2bag`: ``` ### this is 55 + 1 elements: 0 0 0 0 0 0 1 0 0 0 0 0 1 0 0 1 0 0 0 0 0 0 0 0 0 1 0 0 0 0 0 0 1 0 0 0 0 0 0 0 1 0 1 0 0 0 1 0 0 0 0 0 0 2 0 0 ``` Notice for index 53, it is added twice. The fix is ignore the last index from `offsets` when `include_last_offset` is true, also this behavior aligns with CUDA, quote from #57208 (comment) cc jgong5 @XiaobingSuper sanchitintel ashokei jingxu10 [ghstack-poisoned]
|
I'm not sure the new code is better 😂 It's a lot more complicated but still written fairly naively |
ezyang
reviewed
Dec 13, 2022
…e_last_offset is true" This PR is to fix the segfault reported at #89677, this is a `double free` issue caused by `invalid read`. The reported issue broke at slow path for `EmbeddingBag` on float32, at [EmbeddingBag.cpp#L451](https://github.com/pytorch/pytorch/blob/master/aten/src/ATen/native/EmbeddingBag.cpp#L451) Root cause is that `add_indices` has index which exceeds range of `output_data`, for the reported case. The offsets are given as ``` {0, 6, 12, 15, 25, 32, 40, 42, 46, 53, 53} ``` The `indices` has 55 elements and `offsets[-1] != indices.size(0)`. When `include_last_offset` is true, the `output` will be in the shape of {offsets.size(0) - 1, weight.sizes()[1]}, which will be {10, 5}. Originally, `add_indices` will be (i re-arange the 1D tensor by rows, so here 10 rows in total) ``` ### this is 55 elements 0 0 0 0 0 0 1 1 1 1 1 1 2 2 2 3 3 3 3 3 3 3 3 3 3 4 4 4 4 4 4 4 5 5 5 5 5 5 5 5 6 6 7 7 7 7 8 8 8 8 8 8 8 10 10 ``` The last row has index of 10 which is out of range of output tensor whose size is [10, 5]. The reason is `make_offset2bag` at [EmbeddingBag.cpp#L66](https://github.com/pytorch/pytorch/blob/master/aten/src/ATen/native/EmbeddingBag.cpp#L66) would give the following `offset2bag`: ``` ### this is 55 + 1 elements: 0 0 0 0 0 0 1 0 0 0 0 0 1 0 0 1 0 0 0 0 0 0 0 0 0 1 0 0 0 0 0 0 1 0 0 0 0 0 0 0 1 0 1 0 0 0 1 0 0 0 0 0 0 2 0 0 ``` Notice for index 53, it is added twice. The fix is ignore the last index from `offsets` when `include_last_offset` is true, also this behavior aligns with CUDA, quote from #57208 (comment) cc jgong5 @XiaobingSuper sanchitintel ashokei jingxu10 [ghstack-poisoned]
ezyang
approved these changes
Dec 14, 2022
…e_last_offset is true" This PR is to fix the segfault reported at #89677, this is a `double free` issue caused by `invalid read`. The reported issue broke at slow path for `EmbeddingBag` on float32, at [EmbeddingBag.cpp#L451](https://github.com/pytorch/pytorch/blob/master/aten/src/ATen/native/EmbeddingBag.cpp#L451) Root cause is that `add_indices` has index which exceeds range of `output_data`, for the reported case. The offsets are given as ``` {0, 6, 12, 15, 25, 32, 40, 42, 46, 53, 53} ``` The `indices` has 55 elements and `offsets[-1] != indices.size(0)`. When `include_last_offset` is true, the `output` will be in the shape of {offsets.size(0) - 1, weight.sizes()[1]}, which will be {10, 5}. Originally, `add_indices` will be (i re-arange the 1D tensor by rows, so here 10 rows in total) ``` ### this is 55 elements 0 0 0 0 0 0 1 1 1 1 1 1 2 2 2 3 3 3 3 3 3 3 3 3 3 4 4 4 4 4 4 4 5 5 5 5 5 5 5 5 6 6 7 7 7 7 8 8 8 8 8 8 8 10 10 ``` The last row has index of 10 which is out of range of output tensor whose size is [10, 5]. The reason is `make_offset2bag` at [EmbeddingBag.cpp#L66](https://github.com/pytorch/pytorch/blob/master/aten/src/ATen/native/EmbeddingBag.cpp#L66) would give the following `offset2bag`: ``` ### this is 55 + 1 elements: 0 0 0 0 0 0 1 0 0 0 0 0 1 0 0 1 0 0 0 0 0 0 0 0 0 1 0 0 0 0 0 0 1 0 0 0 0 0 0 0 1 0 1 0 0 0 1 0 0 0 0 0 0 2 0 0 ``` Notice for index 53, it is added twice. The fix is ignore the last index from `offsets` when `include_last_offset` is true, also this behavior aligns with CUDA, quote from #57208 (comment) cc jgong5 @XiaobingSuper sanchitintel ashokei jingxu10 [ghstack-poisoned]
…e_last_offset is true" This PR is to fix the segfault reported at #89677, this is a `double free` issue caused by `invalid read`. The reported issue broke at slow path for `EmbeddingBag` on float32, at [EmbeddingBag.cpp#L451](https://github.com/pytorch/pytorch/blob/master/aten/src/ATen/native/EmbeddingBag.cpp#L451) Root cause is that `add_indices` has index which exceeds range of `output_data`, for the reported case. The offsets are given as ``` {0, 6, 12, 15, 25, 32, 40, 42, 46, 53, 53} ``` The `indices` has 55 elements and `offsets[-1] != indices.size(0)`. When `include_last_offset` is true, the `output` will be in the shape of {offsets.size(0) - 1, weight.sizes()[1]}, which will be {10, 5}. Originally, `add_indices` will be (i re-arange the 1D tensor by rows, so here 10 rows in total) ``` ### this is 55 elements 0 0 0 0 0 0 1 1 1 1 1 1 2 2 2 3 3 3 3 3 3 3 3 3 3 4 4 4 4 4 4 4 5 5 5 5 5 5 5 5 6 6 7 7 7 7 8 8 8 8 8 8 8 10 10 ``` The last row has index of 10 which is out of range of output tensor whose size is [10, 5]. The reason is `make_offset2bag` at [EmbeddingBag.cpp#L66](https://github.com/pytorch/pytorch/blob/master/aten/src/ATen/native/EmbeddingBag.cpp#L66) would give the following `offset2bag`: ``` ### this is 55 + 1 elements: 0 0 0 0 0 0 1 0 0 0 0 0 1 0 0 1 0 0 0 0 0 0 0 0 0 1 0 0 0 0 0 0 1 0 0 0 0 0 0 0 1 0 1 0 0 0 1 0 0 0 0 0 0 2 0 0 ``` Notice for index 53, it is added twice. The fix is ignore the last index from `offsets` when `include_last_offset` is true, also this behavior aligns with CUDA, quote from #57208 (comment) cc jgong5 @XiaobingSuper sanchitintel ashokei jingxu10 [ghstack-poisoned]
…e_last_offset is true" This PR is to fix the segfault reported at #89677, this is a `double free` issue caused by `invalid read`. The reported issue broke at slow path for `EmbeddingBag` on float32, at [EmbeddingBag.cpp#L451](https://github.com/pytorch/pytorch/blob/master/aten/src/ATen/native/EmbeddingBag.cpp#L451) Root cause is that `add_indices` has index which exceeds range of `output_data`, for the reported case. The offsets are given as ``` {0, 6, 12, 15, 25, 32, 40, 42, 46, 53, 53} ``` The `indices` has 55 elements and `offsets[-1] != indices.size(0)`. When `include_last_offset` is true, the `output` will be in the shape of {offsets.size(0) - 1, weight.sizes()[1]}, which will be {10, 5}. Originally, `add_indices` will be (i re-arange the 1D tensor by rows, so here 10 rows in total) ``` ### this is 55 elements 0 0 0 0 0 0 1 1 1 1 1 1 2 2 2 3 3 3 3 3 3 3 3 3 3 4 4 4 4 4 4 4 5 5 5 5 5 5 5 5 6 6 7 7 7 7 8 8 8 8 8 8 8 10 10 ``` The last row has index of 10 which is out of range of output tensor whose size is [10, 5]. The reason is `make_offset2bag` at [EmbeddingBag.cpp#L66](https://github.com/pytorch/pytorch/blob/master/aten/src/ATen/native/EmbeddingBag.cpp#L66) would give the following `offset2bag`: ``` ### this is 55 + 1 elements: 0 0 0 0 0 0 1 0 0 0 0 0 1 0 0 1 0 0 0 0 0 0 0 0 0 1 0 0 0 0 0 0 1 0 0 0 0 0 0 0 1 0 1 0 0 0 1 0 0 0 0 0 0 2 0 0 ``` Notice for index 53, it is added twice. The fix is ignore the last index from `offsets` when `include_last_offset` is true, also this behavior aligns with CUDA, quote from #57208 (comment) cc jgong5 @XiaobingSuper sanchitintel ashokei jingxu10 [ghstack-poisoned]
Test case updated! Add a minimal case which would trigger 'double free' issue without this fix. |
ezyang
approved these changes
Dec 15, 2022
|
@pytorchbot merge |
Merge startedYour change will be merged once all checks pass (ETA 0-4 Hours). Learn more about merging in the wiki. Questions? Feedback? Please reach out to the PyTorch DevX Team |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
4 participants
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Stack from ghstack:
This PR is to fix the segfault reported at #89677, this is a
double freeissue caused byinvalid read.The reported issue broke at slow path for
EmbeddingBagon float32, at EmbeddingBag.cpp#L451Root cause is that
add_indiceshas index which exceeds range ofoutput_data, for the reported case.The offsets are given as
The
indiceshas 55 elements andoffsets[-1] != indices.size(0).When
include_last_offsetis true, theoutputwill be in the shape of {offsets.size(0) - 1, weight.sizes()[1]}, which will be {10, 5}.Originally,
add_indiceswill be (i re-arange the 1D tensor by rows, so here 10 rows in total)The last row has index of 10 which is out of range of output tensor whose size is [10, 5].
The reason is
make_offset2bagat EmbeddingBag.cpp#L66 would give the followingoffset2bag:Notice for index 53, it is added twice.
The fix is ignore the last index from
offsetswheninclude_last_offsetis true, also this behavior aligns with CUDA, quote from #57208 (comment)cc @jgong5 @XiaobingSuper @sanchitintel @ashokei @jingxu10