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.

Reply via email to