Comment 0 for bug 1962785

[Impact]
dtrace generates .c code in a predictable temporary file which makes it susceptible to crashes. I've seen this happen in practice when rebuilding libvirt/focal on a system with 48 cores. The race window is wide enough that the crash is nearly 100% reproducible.

[Test Case]
user@host:~$ cat foo/Makefile
all: ../foo/foo.out foo.out

%.out:
 dtrace -o foo.out -G -s /dev/null

clean:
 rm -f foo.out
user@host:~$ cd foo
user@host:~/foo$ make
dtrace -o foo.out -G -s /dev/null
user@host:~/foo$ make clean
rm -f foo.out
user@host:~/foo$ make -j2
dtrace -o foo.out -G -s /dev/null
dtrace -o foo.out -G -s /dev/null
Traceback (most recent call last):
  File "/usr/bin/dtrace", line 455, in <module>
    sys.exit(main())
  File "/usr/bin/dtrace", line 440, in main
    os.remove(fname)
FileNotFoundError: [Errno 2] No such file or directory: 'foo.out.dtrace-temp.c'
make: *** [Makefile:4: ../foo/foo.out] Error 1

[Fix]
https://sourceware.org/git/?p=systemtap.git;a=commit;h=0de9020c970bceda73e32bbd169c12e7579f21ec

[What could go wrong]
It is possible that a race still exists, but the fix should be an overall improvement. Perhaps it is possible that a funky filename string could cause UTF-8 encoding to fail resulting in a crash - though it would seem that such input wouldn't be a valid path name and dtrace would crash anyway.