注释
这看起来像是除以零,可能在第 486 行。我将尝试在下周的某个时间重现该问题。 |
谢谢!我会看看我是否可以想出一个简单的 hal 文件来重现问题(没有硬件) |
如果你是平分那么你能不能把那行注释掉,重新编译并重新测试?如果不使用 missing-index(还),则不需要它的作用。 |
好的 – 这是一个会崩溃的短 hal 文件 – 似乎我不得不将 sim 编码器放在比编码器更快的线程中以使其出错 – 还需要向它发送一个正弦波以使其失败……它会加载后错误秒数。 loadrt threads name1=fastsimthread period1=10000 name2=encoderthread period2=100000 name3=servothread period3=1000000 addf encoder.capture-position servothread net a sim-encoder.0.phase-A encoder.0.phase-A setp sim-encoder.0.ppr 500 setp encoder.0.position 开始 |
q 我把那行注释掉了 cntr->limit_dt += 0.1 * ((*(cntr->missing_teeth) + 0.5) * (delta_time / delta_counts)) 到目前为止没有崩溃 |
它对我来说似乎没有崩溃,这使得修复更加困难。 |
好便便 – 我正在使用 rt-preempt。我只是再次尝试以确保我发布的内容会导致它崩溃 linuxcnc@linuxcnc-pc:~/linuxcnc-dev/src$ halcmd -kf |
我用 preempt-rt 实现了它。不过,我不确定为什么它会有所作为。 |
应该由9471c05 修复 |
预期:什么都不应该发生。
观察到:linuxcnc 因“rtapi_app: caught signal 8 – dumping core”而崩溃
我在这两个提交之间缩小了范围,然后做了一个 git bisect
c8074d7 好
0c79d36 坏
看起来是
作者:andypugh andy@bodgesoc.org
日期:2021 年 7 月 19 日星期一 23:20:27 +0100
:040000 040000 b453ce776bffebee855943a019c8e122c1747aea 1789e99975963859271560f1473a6104cb0c3c67 M docs
:040000 040000 e3ffd27f364a8c7d5933948cd7973a0f1212fbf6 e075746587105c65fc33efeffac5f0cce64c0883 M src
可能只有一个 hal 示例可以显示这一点 – 也许带有编码器和 sim 编码器?我不知道实际问题是什么——与 bari 交谈——这可能是一个基准期内 2 次或更多次转换的问题。
示例.tar.gz