public inbox for systemtap@sourceware.org
 help / color / mirror / Atom feed
* [Bug uprobes/28923] New: dtrace predictable temp file causes race
@ 2022-02-25  0:12 dannf at dannf dot org
  2022-02-25  2:07 ` [Bug uprobes/28923] " fche at redhat dot com
                   ` (6 more replies)
  0 siblings, 7 replies; 8+ messages in thread
From: dannf at dannf dot org @ 2022-02-25  0:12 UTC (permalink / raw)
  To: systemtap

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.

^ permalink raw reply	[flat|nested] 8+ messages in thread
end of thread, other threads:[~2022-03-01 16:06 UTC | newest]

Thread overview: 8+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2022-02-25  0:12 [Bug uprobes/28923] New: dtrace predictable temp file causes race dannf at dannf dot org
2022-02-25  2:07 ` [Bug uprobes/28923] " fche at redhat dot com
2022-02-25 16:06 ` dannf at dannf dot org
2022-02-25 23:29 ` dannf at dannf dot org
2022-02-26  1:14 ` fche at redhat dot com
2022-02-26 16:21 ` dannf at dannf dot org
2022-02-28 17:33 ` dannf at dannf dot org
2022-03-01 16:06 ` fche at redhat dot com

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).