Fix crash in random.shuffle operator

[apeforest]

Description

This PR fix #15029
The rootcause of the problem is when NDArray is 1-d and the platform is GNU Linux, the backend implementation uses __gnu_parallel:random_shuffle() See: https://github.com/apache/incubator-mxnet/blob/master/src/operator/random/shuffle_op.cc#L53. This explains why crash did not happen in MacOS.

The random_shuffle template defined in gcc (https://github.com/gcc-mirror/gcc/blob/master/libstdc%2B%2B-v3/include/parallel/random_shuffle.h#L384) is passing in std::numeric_limits<uint32_t>::max() to the __rng() function to generate random seed. Therefore, in our rng() function (https://github.com/apache/incubator-mxnet/blob/master/src/operator/random/shuffle_op.cc#L49) we cannot use our self defined data type index_t and have to use uint32_t to avoid integer overflow.

Why this bug was not detected in our unit test? Because our unit test of shuffle only tests 2-D shape, which did not use parallel_shuffle in backend.

Checklist

Essentials

Please feel free to remove inapplicable items for your PR.

• The PR title starts with [MXNET-$JIRA_ID], where $JIRA_ID refers to the relevant JIRA issue created (except PRs with tiny changes)
• Changes are complete (i.e. I finished coding on this PR)
• All changes have test coverage:
• Unit tests are added for small changes to verify correctness (e.g. adding a new operator)
• Nightly tests are added for complicated/long-running ones (e.g. changing distributed kvstore)
• Build tests will be added for build configuration changes (e.g. adding a new build option with NCCL)
• Code is well-documented:
• For user-facing API changes, API doc string has been updated.
• For new C++ functions in header files, their functionalities and arguments are documented.
• For new examples, README.md is added to explain the what the example does, the source of the dataset, expected performance on test set and reference to the original paper if applicable
• Check the API doc at http:https://mxnet-ci-doc.s3-accelerate.dualstack.amazonaws.com/PR-$PR_ID/$BUILD_ID/index.html
• To the my best knowledge, examples are either not affected by this change, or have been fixed to be compatible with this change

[stu1130]

LGTM

[zheng-da]

I think you should fix ShuffleND as well.

[samskalicky]

LGTM

[apeforest]

@zheng-da ShuffleND does not use __gnu_parallel:random_shuffle() so there is no issue.

[zheng-da]

thanks for clarifying.

[karan6181]

@mxnet-label-bot add [Operator, pr-awaiting-merge]

[larroy]

LGTM, could you edit the description of the PR and explain why the segfault? is not clear from the description, even though the fix is clear. Why would it segfault? in the linked issue the value doesn't seem to overflow int32... is it an internal implementation problem in the stl?

[apeforest]

@larroy yes, it's the internal implementation of random_shuffle that caused overflow. See the line: (https://github.com/gcc-mirror/gcc/blob/master/libstdc%2B%2B-v3/include/parallel/random_shuffle.h#L384

I already addeded this in the PR description

[larroy]

Thanks, this was not entirely clear, was a range error?