Master: Homing gantry fails on every other attempt

[Sigma1912]

Current master shows a new bug when homing a gantry.

Every time I home my gantry (joints 0&1) with one of the home switches active it fails on the first attempt:

emc/task/taskintf.cc 1006: Error on joint 0, command number 140
joint 0 following error
Cannot unhome while homing, joint 0

If I then retry to home it works, if I retry again it fails, retry again it works etc.

I did a git bisect and got this result (which seems rather unrelated):

user@debian:~/git/linuxcnc-master$ git bisect view
commit e6cc88d34aa1a545f95d7c4053af8ae11e39ce7a (HEAD)
Author: Luca Toniolo <10792599+grandixximo@users.noreply.github.com>
Date:   Mon Aug 24 00:54:58 2026 +1000

    interp: restore the spindle override after an aborted thread
    
    G33 and G76 suspend the spindle override and queue the restore behind the move. An abort clears the interpreter list, so the restore is lost and nothing else re-enables it: the override stays dead until a later thread completes, and Interp::synch() reads that back as the modal M48 or M49 state.
    
    Re-assert it in Interp::on_abort, on the active spindle only. Motion keeps one global enable bit, so looping over every spindle has the inactive ones clear it again.

@grandixximo do you see a possible connection

[grandixximo]

I tried to reproduce this locally and could not.

What e6cc88d does at runtime: after every abort (estop reset, machine off, task abort, motion error) the interpreter queues one extra EMC_TRAJ_SET_SO_ENABLE message. Task executes it like any other queued command and sends EMCMOT_SS_ENABLE to motion, which only sets or clears the spindle override enable bit. Nothing in that path touches joints, the homing state machine or the trajectory mode, so I cannot see how it produces a following error on joint 0.

Could you post:

1. the ini and hal files of the machine (or a link), the GUI used, and the hardware (Mesa stepgen? servo?)
2. the exact order in which the three messages appear
3. a halscope capture of joint.0.pos-cmd, joint.0.motor-pos-fb, joint.0.f-error and joint.0.homing across a failing attempt, so we can see whether the command jumps or the feedback stalls
4. whether current master with e6cc88d reverted still fails; it reverts cleanly:

   git revert --no-commit e6cc88d34a
   cd src && make
   

   A marginal following error would make the bisect land on a random commit.

[grandixximo]

Found a real bug in the homing abort path that fits your error output: HOME_ABORT in homing.c stops the wrong joints. The loop indexes through the local joint pointer, which already points at joints[joint_num], so an abort from joint N stops joints N..N+all_joints-1 instead of 0..all_joints-1. If joint 1 aborts (switch bounce or a limit hit during its backoff), joint 0's planner is never stopped and it faults, which is why your errors name joint 0. With more than 8 joints the write also runs off the end of the joints[] array.

Fix in #4574. Could you try it on your machine and report back whether the alternating failures go away?

[Sigma1912]

Actually, let's just drop this.
My apologies for the churn.

1. I now realize that the issue is more random than I thought and my git bisect result is totally meaningless.
2. That a newly created config does not show this issue at all.

Thanks for your efforts. At least we got one real bug squash out of it.