Rust command line tools keeps beeing killed

Hi,
I'm new to rust. and I'm trying to write a command line tool. A problem encountered when I'm trying to copy the artifact to another path to execute.

It always shown

$ /tmp/jcd
[1]    16957 killed     /tmp/jcd

The exit code is 137

But if it's executed directly in target/debug/jcd, it can be executed normally.

/The/absolute/path/target/debug/jcd
error: the following required arguments were not provided:
  --jar-list <JAR_LIST>

The environment is Apple M1. I have no good idea how to debug this problem, Can someone give me some suggestion ?

Thanks.

...may be the problem. Trying placing the program in a different directory like your home directory.

I agree. It could well be that on this system /tmp has the noexec flag set.

mount | grep tmp could be tried to see which flags are set.

Thanks for your reply. I try to place it to other folder it works as expected.

However, on mac, I can not see the tmp mount with mount | grep tmp

but

$ mount
/dev/disk3s3s1 on / (apfs, sealed, local, read-only, journaled)
devfs on /dev (devfs, local, nobrowse)
/dev/disk3s6 on /System/Volumes/VM (apfs, local, noexec, journaled, noatime, nobrowse)
/dev/disk3s4 on /System/Volumes/Preboot (apfs, local, journaled, nobrowse)
/dev/disk3s2 on /System/Volumes/Update (apfs, local, journaled, nobrowse)
/dev/disk1s2 on /System/Volumes/xarts (apfs, local, noexec, journaled, noatime, nobrowse)
/dev/disk1s1 on /System/Volumes/iSCPreboot (apfs, local, journaled, nobrowse)
/dev/disk1s3 on /System/Volumes/Hardware (apfs, local, journaled, nobrowse)
/dev/disk3s1 on /System/Volumes/Data (apfs, local, journaled, nobrowse, protect)
map auto_home on /System/Volumes/Data/home (autofs, automounted, nobrowse)
/dev/disk3s3 on /System/Volumes/Update/mnt1 (apfs, sealed, local, journaled, nobrowse)

But one more strange thing, I also tried put an another example "hello world" binary in /tmp too, It can be executed.

$ /tmp/std_mem_test
hello

The content of the example is

fn main() {
    println!("hello");
}

If the /tmp has the noexec flag set, I think it also should not work for this program :thinking:

I’m not sure how much help this is, but this is a ticket for CMake discussing a similar problem: macOS: Linker-signed libraries signed at install-time crash with hardened runtime (#22372) · Issues · CMake / CMake · GitLab

One of the suggestions there is to use ditto instead of cp or install when copying executables around. Apart from that, I don’t know enough about macOS linking and code signing to say what the problem is.

1 Like

Thank you for your valuable information. I check the crash log, and I found the exception msg below

It appears to be genuinely caused by the issue of "Code Signature Invalid".

Also tried the "ditto" to copy the binary, It works well.

1 Like

This topic was automatically closed 90 days after the last reply. We invite you to open a new topic if you have further questions or comments.