iRT存在double free和core dump问题

[WennyAhhh]

运行环境

iEDA docker

测例

我并非使用标准的数字流程，而是仅使用Lef、Def完成布线流程，相关数据因为NDA无法提供。

问题

由于布线资源较为紧张，会产生大量违例。 在运行5个小时并跑完10次布线迭代完成之后，出现core dump错误或者是double free，依据rt.log和gdb我找到错误的函数为

void DataManager::updateViolationToGCellMap(ChangeType change_type, Violation* violation)

其中的violation指针已经为空，但是依然进行了free。

  if (change_type == ChangeType::kDel) {
    delete violation;
    violation = nullptr;
  }

我通过增加以下判断指针是否为空规避了这个问题，此后再跑此处就没有问题。

  if (violation == nullptr) {
    return;
  }

本可以提交pr完成debug修复，但是我仔细研究了一下布线算法，发现其在处理violation时某一函数存在数据竞争问题。以下函数在并发环境下在RTDM中删除violation，即便我可以看到dr_box已经做了错位处理以避免相邻并发单元互相冲突，但是在违例较多的情况下，是否依然存在数据竞争？

void DetailedRouter::buildViolation(DRBox& dr_box)

所以我认为以上的判断语句仅能修复我的例子，或许并不能根本解决我遇到的问题。此问题已经超出了我个人修bug的范围，望开发组可以看一下这个问题。如果我的表述存在问题，希望批评指正。

[ZhishengZeng]

您好，感谢您提供如此详细的问题定位与规避方案。

该问题我们在开发阶段已做过较为谨慎的处理，但仍可能在一些 corner case 下触发异常。

并行化处理中，违例通常通过拉大并行任务间距来规避冲突；若仍出现空指针/重复释放等异常，可能是违例范围超过了最小间距（一般约为 24 倍 pitch）导致覆盖关系变复杂，但按常规情况这类超大违例并不常见。

我们在开发过程中也遇到过类似的并发竞争问题。由于开源版本与内部开发版本存在一定差异，不排除该问题在后续版本中已被修复或缓解。

您增加的判空处理确实能够提升程序鲁棒性、减少空指针相关崩溃风险，我们也会考虑以类似方式进行加强；同时我们也希望进一步定位导致该现象的根因，以便从根本上解决问题。

烦请您在不违反 NDA 的前提下，尽可能提供更详细的信息（例如 rt.log 关键片段、gdb backtrace、运行配置/线程数、是否稳定复现等），以便我们复现并开展针对性修复。再次感谢！