https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120029
Bug ID: 120029 Summary: Dangling iterator usage in std::filesystem::path::operator+=(const std::filesystem::path &p) when this == p Product: gcc Version: 16.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: libstdc++ Assignee: unassigned at gcc dot gnu.org Reporter: yhx12243 at gmail dot com Target Milestone: --- Created attachment 61253 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=61253&action=edit Contains a source code and its crash demo. There are following code snippets in https://github.com/gcc-mirror/gcc/blob/85e4f21f9e90fc70b8c7c75ec8e4d0766008ac6e/libstdc%2B%2B-v3/src/c%2B%2B17/fs_path.cc#L917-L983: > 913 _Cmpt* it = nullptr; > 914 _Cmpt* last = nullptr; > 915 if (p._M_type() == _Type::_Multi) > 916 { > 917 it = p._M_cmpts._M_impl->begin(); > 918 last = p._M_cmpts._M_impl->end(); > 919 } > ...... > 983 _M_cmpts.reserve(capacity); > ...... > 1031 ::new(output++) _Cmpt(it->_M_pathname, _Type::_Filename, pos); AWhen this == p, the iterator created by L917-L918 will be invalidated by L983: _M_cmpts.reserve(capacity), however it is still used later (e.g., in L1031), result in a potential segmentation fault. In addition, it indeed fails on my computer and I've found out by gdb it is caused by this dangling iterator usage.