[tor-bugs] #32053 [Applications/Tor Browser]: macOS bundles for Tor Browser 9.0a8 are not reproducible

[Tor Bug Tracker & Wiki]

#32053: macOS bundles for Tor Browser 9.0a8 are not reproducible
-------------------------------------------------+-------------------------
 Reporter:  gk                                   |          Owner:  tbb-
                                                 |  team
     Type:  defect                               |         Status:  new
 Priority:  Immediate                            |      Milestone:
Component:  Applications/Tor Browser             |        Version:
 Severity:  Critical                             |     Resolution:
 Keywords:  TorBrowserTeam201911, tbb-9.0-must,  |  Actual Points:
  tbb-9.0-issues, tbb-regression,                |
  tbb-9.0.1-can, GeorgKoppen201911               |
Parent ID:                                       |         Points:
 Reviewer:                                       |        Sponsor:
-------------------------------------------------+-------------------------

Comment (by gk):

 Replying to [comment:18 alexcrichton]:
 > Nice!
 >
 > I agree with that conclusion as well in that it looks like LLVM may have
 a nondeterministic optimization somewhere in it. Can you upload the `*.bc`
 files so I could poke around at them? Both the `no-opt` and optimized
 versions if you can. Also, what rustc commit are you using? I'll try to
 get the same set of LLVM tools used on that commit.

 I uploaded the files to https://people.torproject.org/~gk/misc/32053/ with
 the sha256sums as given in comment:17. We are using the 1.34.2 tag but if
 things are easier for you I can recreate the `.bc` files with the
 currently stable Rust as the issue is still there. BTW: thanks for your
 help, that's really appreciated.

 > In terms of how to keep minimizing, I think the first step is to use
 100% pure LLVM tools to reproduce this. For example "run this command 1000
 times and I get different results between runs".

 That's my current plan. I am not familiar with the LLVM tools both in
 terms of which to use best and which parameters to deploy but ideally I
 like to take the `no-opt.bc` file from above, run just the optimization
 with some LLVM tool N times and hit the bug at some point. That should be
 fast enough to allow a meaningful Rust/LLVM bisect if needed.

 > Given that the next best step would probably be to use `bugpoint` from
 LLVM to help reduce the input IR file into something smaller. Historically
 `bugpoint` has been a massive pain to use, but
 http://blog.llvm.org/2015/11/reduce-your-testcases-with-bugpoint-and.html
 was somewhat helpful to me in the past. The general idea is that you'll
 write a script which says whether an input module is "interesting", and in
 this case "interesting" means "I ran some LLVM optimizations a few times
 and it didn't always produce the same result".
 >
 > In any case I can try to help with the `bugpoint` process once I'm able
 to reproduce with the input LLVM modules.

 Thanks!

--
Ticket URL: <https://trac.torproject.org/projects/tor/ticket/32053#comment:19>
Tor Bug Tracker & Wiki <https://trac.torproject.org/>
The Tor Project: anonymity online