Коротко: R.pop_back() падает не потому, что «вектор обязательно пустеет логически», а потому что в какой-то итерации к моменту вызова pop_back() у R действительно size()==0 (или разрушается «битый» элемент). Ниже — самые частые причины именно при таком паттерне pop_heap → move R.back() → pop_back() и что проверить.

Что проверить в первую очередь

1. Гарантируете ли непустоту перед pop_heap/pop_back

• Перед std::pop_heap(R.begin(), R.end(), Compare); добавьте защиту:

  cpp
  if (R.empty()) { /* лог/ассерт */ return Extr; }

  Если сработает — значит где-то ранее вы вышли из цикла без «восполнения» кучи.

2. Правильность логики выхода

• В вашем коде из функции можно выйти после того как вы уже вынули элемент из кучи, но до того как добавили два новых:

  cpp
  std::pop_heap(...);
  Interval i = std::move(R.back());
  R.pop_back();                         // уменьшили size
  ...
  if (++schetchick == global_iterations || dmin < epsilon) {
      return Extr;                      // выход без возвращения интервала назад
  }

  Это нормально (вы просто выходите), но на следующей итерации цикла вы уже не будете (вы вышли). Так что эта часть не делает R пустым «для следующего pop_back».
  Если исключение возникает именно на pop_back в той же итерации — значит проблема не в этом «раннем выходе».

3. Корректность компаратора Compare

• Для алгоритмов кучи Compare обязан задавать строгий слабый порядок (Strict Weak Ordering). Любые нарушения (недетерминизм, зависимость от меняющихся полей без переупорядочивания, NaN в сравниваемых значениях и т. п.) приводят к UB и повреждению внутреннего состояния вектора/кучи, что легко «выстрелит» на pop_back.
• Вы изменяете R[i].M и длины интервалов. Где вы меняли ключи кучи, вы вызвали std::make_heap(R.begin(), R.end(), Compare); — это хорошо. Убедитесь, что во всех ветках, где меняются поля, влияющие на порядок (то, по чему сравнивает Compare), вы действительно делаете reheapify.

4. Изменение элементов без reheapify

• В ветке:

  cpp
  else {
      curr.ChangeCharacteristic(m, N);
      curr1.ChangeCharacteristic(m, N);
      // R[i] не меняли → make_heap не нужен
  }

  Это ок, если Compare не зависит от других полей в R[i]. Но если ChangeCharacteristic косвенно влияет на то, как Compare сравнит элементы (например, через общий глобальный коэффициент), потребуется make_heap.

5. Исключение/авария в деструкторе/перемещении Interval

• Строка:

  cpp
  Interval promejutochny_otrezok = std::move(R.back());
  R.pop_back();

  вызывает деструктор элемента на конце. Если у Interval деструктор бросает (нельзя), assert’ится, или опирается на инварианты, нарушающиеся после перемещения — исключение прилетит на pop_back(). Проверьте:
  • Деструктор ~Interval() — noexcept и безопасен для «перемещённого» состояния.
  • Move-ctor/Move-assign корректно «зануляют» ресурсы.
  • Нет «двойного освобождения» ресурсов (сырой delete/free).

6. NaN и сравнения с float

• Если Compare использует float поля (M, длина интервала) и туда закрадывается NaN, любые сравнения становятся непредсказуемыми → куча ломается.
  Проверьте расчёты: dmax, GLOBAL_FACTOR, MULTIPLIER = (1.0f / dmax) * Mmax (если dmax==0, деление!), fmaf, т. п. Добавьте ранние проверки:

  cpp
  assert(std::isfinite(dmax) && dmax > 0);
  assert(std::isfinite(Mmax));
  assert(std::isfinite(curr.M) && std::isfinite(curr1.M));

7. Начальное состояние кучи

• После R.emplace_back(...) вы не делаете make_heap. Для size()==1 это ок (куча тривиальна). Но как только размер >1, вы строго поддерживаете кучу через push_heap — это правильно. Убедитесь, что нигде не попадает во R элемент обходя push_heap.

8. Порядок pop_heap/move/pop_back

• Ваш порядок корректный:
  1. pop_heap → максимальный элемент уходит в back();
  2. move из back();
  3. pop_back разрушает перемещённый элемент.
     Не меняйте местами.

Как отладить быстро

• Включите проверки в отладке (MSVC): _ITERATOR_DEBUG_LEVEL=2, ассерты на пустоту и std::isfinite.
• Логируйте размер до и после операций:

  cpp
  assert(!R.empty());
  std::pop_heap(...);
  // здесь size тот же
  // R.back() валиден
  Interval x = std::move(R.back());
  R.pop_back(); // size--, деструктор

• На время отладки замените Interval на POD/тривиальный тип или сделайте пустой деструктор — если падение исчезло, проблема в деструкторе/перемещении.

Возможное «пуленепробиваемое» исправление

Если выяснится, что иногда вы меняете ключи элементов без reheapify, то самый простой «страховочный» шаг — всегда пересобирать кучу после любых модификаций полей, влияющих на порядок:

cpp
// После любых ChangeCharacteristic, которые влияют на Compare:
std::make_heap(R.begin(), R.end(), Compare);

И убедитесь, что деления на dmax безопасны (dmax>0) и что Compare — чистая функция по полям элемента.

Если пришлёте код Interval и Compare, скажу точнее, что именно ломает кучу/деструктор.