Stale headers in include/ after commit 82f05bcc cause shared memory size mismatch

[grandixximo]

Summary

Commit 82f05bc ("build: Fix include copying, references and RT/non-RT isolation") removed ~30 headers from SRCHEADERS, so they are no longer copied from src/emc/{motion,tp,kinematics,ini,nml_intf}/ to include/. Direct -I flags were added so source files find them in src/ instead.

However, the existing stale copies in include/ were never deleted, and make clean / headersclean no longer removes them (since they're no longer in HEADERS). Any working tree that existed before the commit retains the old copies.

Impact

The stale include/ headers silently shadow the real src/ headers when both are in the -I search path (which they are — -I../include appears in compile flags). If a struct-size-affecting field is added or removed in src/, the stale include/ copy keeps the old layout. This causes:

• Shared memory size mismatch between motmod (finds src/emc/motion/motion.h) and milltask (finds include/motion.h via -I../include), resulting in shmget(): Invalid argument (EINVAL) at startup
• Silent shared memory corruption if the sizes happen to match but layouts differ

The specific error:

rtapi_shmem_new failed due to shmget(key=0x00000064): Invalid argument
MOTION: rtapi_shmem_new failed, returned -22
MOTION: init_comm_buffers() failed

Affected headers

All headers removed from SRCHEADERS in 82f05bc that may still exist in include/:

motion.h state_tag.h axis.h blendmath.h simple_tp.h spherical_arc.h
usrmotintf.h tc.h tc_types.h tcq.h tp.h tp_types.h homing.h switchkins.h
cubic.h genhexkins.h genserkins.h pentakins.h pumakins.h motion_types.h
sp_scurve.h canon.hh canon_position.hh emctool.h emc.hh emc_nml.hh
emccfg.h emcglb.h interp_return.hh emcIniFile.hh iniaxis.hh inijoint.hh
inispindle.hh initraj.hh inihal.hh

Suggested fix

Either:

1. Add an explicit rm -f for these files in the commit (or a follow-up), so users pulling the change get them cleaned automatically
2. Add them to headersclean / make clean so they are always swept

Option 2 is more robust since it handles any future SRCHEADERS removals.

Reproduction

1. Have a working tree with include/ populated from before 82f05bc
2. Pull the commit (headers stop being updated but stale copies remain)
3. Make any struct-size-affecting change in src/emc/motion/ or src/emc/tp/
4. make clean && make — stale include/ copies are not cleaned
5. Launch LinuxCNC — shmget fails with EINVAL due to size mismatch

[grandixximo]

@BsAtHome Thoughts?

[BsAtHome]

Run git clean -dxf . in the base directory (where you cloned lcnc). Warning: it will remove untracked files and can therefore remove uncommitted work if you are not careful. You should save your work before git clean.

Lingering files is a known issue of the build setup. It also happens once in a while when you switch between master and 2.9. Very annoying, but fixing it is hard because sources and build targets are not cleanly separated (for that you'd like a separate "build" directory outside the src-tree).

The fix for the include problem would be to add something like $(RM) ../include/*.h ../include/*.hh to the clean target. But I'm not sure this is the really correct solution.

[grandixximo]

You'd have to exclude
/include/comp_kins_uspace.h which is in the repo.
yeah it gets messy...
I have solved with a script

/.git/hooks/post-checkout

#!/bin/bash
# Clean stale build artifacts from include/ after branch switch
# Only run on branch checkouts (not file checkouts)
if [ "$3" != "1" ]; then
    exit 0
fi

cd "$(git rev-parse --show-toplevel)" || exit 0

# Remove all build-artifact headers from include/ (they're gitignored)
git clean -fX include/ 2>/dev/null

echo "post-checkout: cleaned stale headers from include/"

at least on my machine is fixed...

[BsAtHome]

There shouldn't be any files in basedir/include and they should all be copied in. If this is not the case, then it should be fixed.

I cannot see any such files in master or 2.9 branch, so I you probably put it there. Then the question is, why and what does it do?

Looking in your repo, it seems to have a lot of code in that header... That is generally a bad choice. That code does not look to belong in a header, but in a library.

[grandixximo]

Will do

[grandixximo]

I guess this is only relevant for devs who switch a lot between commits.
make clean is not enough

git clean -dxf .

will do the trick but use with care.

should I close?

anyone thinks

$(RM) ../include/*.h ../include/*.hh

is a better solution?

@andypugh

[andypugh]

I have always relied on git clean when things seem messed up.
There is probably an argument for adding that to the build instructions.