Hi Ningna，您好！
首先非常感谢您开源并维护 MATTopo，这个项目对我们目前的研究工作帮助很大。
我在使用 non_cad 模式 测试 MATTopo 时，遇到了一个稳定可复现的 segmentation fault。目前已经通过 gdb 基本定位到问题根源，想向您确认这是已知问题，还是我这边使用方式不当。
复现方式
使用 non_cad 模式运行，例如：
./bin/MATTOPO Ours_3000.msh 30 non_cad 0.1
程序可以顺利完成以下阶段：
- 四面体网格（.msh）加载
- sharp / concave feature 检测
- RPD（GPU）计算
- medial mesh 构建
- surface sampling
随后在 fix_geo / shrink 阶段发生 segmentation fault。
gdb 定位结果
使用 gdb 得到的 backtrace 显示，崩溃稳定发生在以下调用链中：
SurfaceMesh::collect_kring_neighbors_given_fid
TangentConcaveLine::update_covered_sf_fids
TangentConcaveLine::TangentConcaveLine
MedialSphere::update_tan_cc_lines_from_ss_params
shrink_post_process
shrink_sphere
add_new_sphere_given_v2fid
check_and_fix_mm_geo
实际的崩溃点出现在 std::set::clear() 内部，表现为非法内存访问。
一些关键发现
在 SurfaceMesh::collect_kring_neighbors_given_fid() 中，参数 tan_fid 经常取到明显非法的值，例如：
而在当前 surface mesh 中，合法范围应当是：
0 <= tan_fid < sf_mesh.facets.nb()
我在该函数中加入了简单的防护检查：
if (tan_fid < 0 || tan_fid >= sf_mesh.facets.nb()) {
std::cerr << "[WARN] invalid tan_fid=" << tan_fid << std::endl;
return false;
}加入后可以看到大量 warning 输出，随后程序仍会在 fix_geo 后续阶段崩溃，说明这是一个系统性问题，而非偶发错误。
当前理解（希望向您确认）
从调用关系和行为来看，问题可能源于：
- TangentConcaveLine 内部保存的 tan_fid
- 在 fix_geo / shrink 过程中，medial spheres / feature lines 被删除、合并或重建
- 但部分 TangentConcaveLine 对象仍然持有已经失效的 surface face id
从而在后续的 k-ring neighbor 查询中触发非法内存访问并最终 segfault。
想请教的问题
1. 在 non_cad 模式 下，fix_geo 阶段是否默认假设输入 surface 的拓扑在此阶段保持稳定？
2. TangentConcaveLine / tan_fid 在 shrink / fix 过程中，是否需要额外的生命周期管理或刷新机制？
3. 这个问题是否是当前代码中已知但尚未修复的情况？是否有推荐的 workaround（例如在 non_cad 模式下临时跳过某类 CC line 或 fix_geo 子流程）？
非常感谢您的时间和指导！如果需要更详细的日志、backtrace 或测试数据，我可以进一步补充。
Hi Ningna，您好！
首先非常感谢您开源并维护 MATTopo，这个项目对我们目前的研究工作帮助很大。
我在使用 non_cad 模式 测试 MATTopo 时，遇到了一个稳定可复现的 segmentation fault。目前已经通过 gdb 基本定位到问题根源，想向您确认这是已知问题，还是我这边使用方式不当。
复现方式
使用 non_cad 模式运行，例如：
程序可以顺利完成以下阶段：
随后在 fix_geo / shrink 阶段发生 segmentation fault。
gdb 定位结果
使用 gdb 得到的 backtrace 显示，崩溃稳定发生在以下调用链中：
实际的崩溃点出现在 std::set::clear() 内部，表现为非法内存访问。
一些关键发现
在 SurfaceMesh::collect_kring_neighbors_given_fid() 中，参数 tan_fid 经常取到明显非法的值，例如：
而在当前 surface mesh 中，合法范围应当是：
我在该函数中加入了简单的防护检查：
加入后可以看到大量 warning 输出，随后程序仍会在 fix_geo 后续阶段崩溃，说明这是一个系统性问题，而非偶发错误。
当前理解（希望向您确认）
从调用关系和行为来看，问题可能源于：
从而在后续的 k-ring neighbor 查询中触发非法内存访问并最终 segfault。
想请教的问题
1. 在 non_cad 模式 下，fix_geo 阶段是否默认假设输入 surface 的拓扑在此阶段保持稳定？
2. TangentConcaveLine / tan_fid 在 shrink / fix 过程中，是否需要额外的生命周期管理或刷新机制？
3. 这个问题是否是当前代码中已知但尚未修复的情况？是否有推荐的 workaround（例如在 non_cad 模式下临时跳过某类 CC line 或 fix_geo 子流程）？
非常感谢您的时间和指导！如果需要更详细的日志、backtrace 或测试数据，我可以进一步补充。