-
Notifications
You must be signed in to change notification settings - Fork 57
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
unordered_set move leads to crash in 1.80.0 #139
Comments
Even simpler (no double move):
|
ergpudb
changed the title
unordered_set double move leads to crash in 1.80.0
unordered_set move leads to crash in 1.80.0
Aug 16, 2022
Thank you for the bug report! I've replicated this issue locally and am aware of the cause. I'm working on the fix. |
bob-beck
pushed a commit
to openbsd/ports
that referenced
this issue
Aug 30, 2022
@ergpudb this fix will be landing in 1.81. In the interim, I'm going to close the issue. |
rwgk
pushed a commit
to rwgk/pybind11
that referenced
this issue
Dec 29, 2023
boostorg/unordered#139 > Based on the standard, the first move should leave a in a "valid but unspecified state";
rwgk
pushed a commit
to rwgk/pybind11
that referenced
this issue
Dec 29, 2023
boostorg/unordered#139 > Based on the standard, the first move should leave a in a "valid but unspecified state";
rwgk
referenced
this issue
in pybind/pybind11
Dec 29, 2023
Clazy's warning (non-pod-global-static) is not relevant for test code.
rwgk
pushed a commit
to pybind/pybind11
that referenced
this issue
Dec 30, 2023
* stl.h: Use C++11 range-loops with const reference This saves copy-ctor and dtor for non-trivial types by value Found by clazy (range-loop-reference) * test_smart_ptr.cpp cleanup Introduce `pointer_set<T>` boostorg/unordered#139 > Based on the standard, the first move should leave a in a "valid but unspecified state"; --------- Co-authored-by: Ralf W. Grosse-Kunstleve <[email protected]>
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
This code segfaults in 1.80.0 but not 1.79.0 (nor using std::unordered_set):
Based on the standard, the first move should leave
a
in a "valid but unspecified state"; sincea
should still be valid, moving from it a second time presumably should not corruptc
(even if the contents ofc
are technically unspecified afterward).Note: it appears that unordered_map also exhibits the same behavior.
The text was updated successfully, but these errors were encountered: