[Bug uprobes/28923] New: dtrace predictable temp file causes race

["dannf at dannf dot org" <sourceware-bugzilla@sourceware.org>]

https://sourceware.org/bugzilla/show_bug.cgi?id=28923

            Bug ID: 28923
           Summary: dtrace predictable temp file causes race
           Product: systemtap
           Version: unspecified
            Status: UNCONFIRMED
          Severity: normal
          Priority: P2
         Component: uprobes
          Assignee: systemtap at sourceware dot org
          Reporter: dannf at dannf dot org
  Target Milestone: ---

Hi!

I've been seeing an issue when re-building the libvirt package from Ubuntu
20.04 on a 48-core system where it frequently crashes in dtrace. I created a
simple reproducer for it:

------------------------------
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
------------------------------

Here we have 2 targets that actually resolve to the same file. It seems like
something about the way pattern matching (%) works prevents make from realizing
that. So, a parallel make will execute 2 dtrace processes to build the same
file. Because dtrace uses the same temporary filename for both -
foo.out.dtrace-temp.c - they race, and one dtrace delete the file while the
other is still processing it. Calling dtrace w/ -k works around the problem for
me because it prevents the first dtrace process from trying to delete the file.
But that likely just leaves a harder-to-hit race where one dtrace process tries
to re-write the process while the other is processing it.

The reason dtrace uses the same temp filename is for reproducible builds:
 
https://sourceware.org/git/?p=systemtap.git;a=commitdiff;h=c245153ca193c471a8c8a2650834dc2f0b801bc1

The reproducible builds project suggests an alternative method of overriding
the .file directive:
  https://reproducible-builds.org/docs/randomness/

Unfortunately I haven't found a good way to override .file outside of an
assembly file.

  -dann

-- 
You are receiving this mail because:
You are the assignee for the bug.