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

Tor Bug Tracker & Wiki blackhole at torproject.org
Mon Nov 4 21:54:26 UTC 2019


#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):

 Okay, here come some promising results:
 {{{
 sha256sum test1/obj-macos/x86_64-apple-darwin/release/deps/style-
 eb257c29b0562cc6.*
 710f7c33fdf586735275ac82bae0e857dbbda4e4a9e2b95498b18231bb347a23  test1
 /obj-macos/x86_64-apple-darwin/release/deps/style-
 eb257c29b0562cc6.4rg6haojvyp4bm84.rcgu.bc
 e0a5bc12a4a2933e4386a25263c148e9c9c0798adcf3a5da83c19e2897eca09d  test1
 /obj-macos/x86_64-apple-darwin/release/deps/style-
 eb257c29b0562cc6.4rg6haojvyp4bm84.rcgu.o
 eeaec097f1e7170a6229e575edee88ae04cfab4d878650bd6b9f00fe6dc7ed75  test1
 /obj-macos/x86_64-apple-darwin/release/deps/style-eb257c29b0562cc6.d
 73066b1c98f66cb36ae83096f411910b55c41494c2d808738ade3d4f27c97847  test1
 /obj-macos/x86_64-apple-darwin/release/deps/style-eb257c29b0562cc6.style
 .5crbtq6r-cgu.0.rcgu.bc
 50a8624628f83c5e5e522b1389bb649f59ea0b162aed8f3dd961dc363d0d68f3  test1
 /obj-macos/x86_64-apple-darwin/release/deps/style-eb257c29b0562cc6.style
 .5crbtq6r-cgu.0.rcgu.bc.z
 d1ef8bb757d3958cbab4a29a900e105ce0cc3a515af01103ceec1502a4281fe0  test1
 /obj-macos/x86_64-apple-darwin/release/deps/style-eb257c29b0562cc6.style
 .5crbtq6r-cgu.0.rcgu.no-opt.bc
 b1ae81ef931a8de03edc613d6685ca263585484d65a5a73c1195115541f452cd  test1
 /obj-macos/x86_64-apple-darwin/release/deps/style-eb257c29b0562cc6.style
 .5crbtq6r-cgu.0.rcgu.o

 sha256sum test2/obj-macos/x86_64-apple-darwin/release/deps/style-
 eb257c29b0562cc6.*
 710f7c33fdf586735275ac82bae0e857dbbda4e4a9e2b95498b18231bb347a23  test2
 /obj-macos/x86_64-apple-darwin/release/deps/style-
 eb257c29b0562cc6.4rg6haojvyp4bm84.rcgu.bc
 e0a5bc12a4a2933e4386a25263c148e9c9c0798adcf3a5da83c19e2897eca09d  test2
 /obj-macos/x86_64-apple-darwin/release/deps/style-
 eb257c29b0562cc6.4rg6haojvyp4bm84.rcgu.o
 eeaec097f1e7170a6229e575edee88ae04cfab4d878650bd6b9f00fe6dc7ed75  test2
 /obj-macos/x86_64-apple-darwin/release/deps/style-eb257c29b0562cc6.d
 061ac74571a2f59ec2f656f0c625093949300a80010d16fce04ac876498ff9d1  test2
 /obj-macos/x86_64-apple-darwin/release/deps/style-eb257c29b0562cc6.style
 .5crbtq6r-cgu.0.rcgu.bc
 e98eb35706f10ce5559d63fa1fdd25de3673b45bf9113d14800db42187a7d4c8  test2
 /obj-macos/x86_64-apple-darwin/release/deps/style-eb257c29b0562cc6.style
 .5crbtq6r-cgu.0.rcgu.bc.z
 d1ef8bb757d3958cbab4a29a900e105ce0cc3a515af01103ceec1502a4281fe0  test2
 /obj-macos/x86_64-apple-darwin/release/deps/style-eb257c29b0562cc6.style
 .5crbtq6r-cgu.0.rcgu.no-opt.bc
 c3a1f4c3180f41ba5031c85d502c368ea9352fd2d4abb7e93bc2e5a3ed77d783  test2
 /obj-macos/x86_64-apple-darwin/release/deps/style-eb257c29b0562cc6.style
 .5crbtq6r-cgu.0.rcgu.o
 }}}
 The important part here is that the `style-eb257c29b0562cc6.style
 .5crbtq6r-cgu.0.rcgu.no-opt.bc` files *are* matching while the `style-
 eb257c29b0562cc6.style.5crbtq6r-cgu.0.rcgu.bc` ones do not. Assuming `no-
 opt` means not-optimized then the problem happens in the optimization
 step(?) for the bytecode, so I guess the "LLVM is non-deterministically
 optimizing IR" step you mentioned above.

 So, it seems to be an LLVM problem. Do you know whether we could work
 around that? Like using no-opt.bc for now? More importantly, though, do
 you have an idea how a small repro test could look like based on that
 information? Back in the day when working on #26475 you saved my day when
 you [https://github.com/rust-lang/rust/issues/52044#issuecomment-402349038
 came up with a test snippet] for an unrelated issue, so I could avoid
 staring at `libstyle`. I have the same hope for this issue. :)

 I can look at the actual diff in the .bc files tomorrow if you think that
 would be helpful.

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


More information about the tor-bugs mailing list