Opened 3 months ago

Closed 2 months ago

#27865 closed defect (fixed)

Tor Browser 8.5a2 is crashing on Windows

Reported by: boklm Owned by: tbb-team
Priority: Very High Milestone:
Component: Applications/Tor Browser Version:
Severity: Normal Keywords: tbb-crash, TorBrowserTeam201810R
Cc: pospeselr, mcs, brade, tom, ezio Actual Points:
Parent ID: Points:
Reviewer: Sponsor:

Description

According to reports in the blog comments, Tor Browser 8.5a2 is crashing on Windows:
https://blog.torproject.org/new-release-tor-browser-85a2

Child Tickets

Change History (19)

comment:1 Changed 3 months ago by boklm

I disabled the update to 8.5a2 for Windows users until the issue is fixed.

I added these lines in the update_responses .htacess file:

# Temporarily disable update for Windows users
RewriteRule ^WINNT_x86-gcc3/.* https://aus1.torproject.org/torbrowser/update_8.5a1/alpha/$0 [last]
RewriteRule ^WINNT_x86-gcc3-x64/.* https://aus1.torproject.org/torbrowser/update_8.5a1/alpha/$0 [last]
RewriteRule ^WINNT_x86_64-gcc3-x64/.* https://aus1.torproject.org/torbrowser/update_8.5a1/alpha/$0 [last]

comment:2 Changed 3 months ago by boklm

I have been able to reproduce the issue with the nightly build from 2018-09-24. However the build from 2018-09-17 is starting correctly.

comment:3 Changed 3 months ago by boklm

So it seems the crash is caused by commit f49b8306354f68dcaf8efeec8a4bd8b5a8908e6b (bug #27623). Reverting that patch is fixing the issue.

comment:4 Changed 3 months ago by gk

Cc: mcs brade added
Keywords: tbb-crash TorBrowserTeam201809 added

comment:5 Changed 3 months ago by gk

Cc: tom added

comment:6 Changed 3 months ago by gk

Cc: ezio added

#27866 is a duplicate.

comment:7 Changed 3 months ago by gk

I think if we need to revert the fix for #27623, then we should only do so for the Windows part as it seems macOS and Linux are fine (and it would be good to test those two platforms further to find (other) lurking issues).

comment:8 Changed 3 months ago by gk

I wonder if that one is related to #26476.

comment:9 in reply to:  8 ; Changed 3 months ago by mcs

Replying to gk:

I wonder if that one is related to #26476.

Interesting and quite possible, because the crash seems to happen very early (before the browser profile is touched). Both 32bit and 64bit builds are affected. Kathy and I are preparing to travel today and won't have time to look at this before we leave. We did briefly review the code that is enabled by MOZILLA_OFFICIAL=1, but we didn't see anything obvious that might cause a crash. If I understand what happened with #26476, a good question to answer would be "Does MOZILLA_OFFICIAL=1 somehow turn on --enable-release?"

comment:12 Changed 3 months ago by gk

Still, what makes me wondering here is why the two patches we added for fixing #26476 do not help here if it is indeed the underlying issue...

comment:13 in reply to:  12 Changed 3 months ago by reportUrl

You didn't fix #26476. You just reverted two Mozilla's patches, one of which enabled --enable-release. But MOZILLA_OFFICIAL=1 adds --enable-release the other way. No?

comment:14 Changed 2 months ago by gk

Keywords: TorBrowserTeam201809R added; TorBrowserTeam201809 removed
Status: newneeds_review

Okay, see bug_27865 (https://gitweb.torproject.org/user/gk/tor-browser-build.git/commit/?h=bug_27865&id=f73c0b90065ed8b487d6f4deac5ae3a88a8b5c3b) in my public tor-browser-build repo. I add the fix to that repo as the other related stopgap patches are already there (hopefully we track the problem down soon to get rid of those stopgaps again).

Let me know whether that looks okayish. I'll start some testbuilds meanwhile.

comment:15 Changed 2 months ago by gk

Okay, okay. Let's actually take bug_27865_v2 (https://gitweb.torproject.org/user/gk/tor-browser-build.git/commit/?h=bug_27865_v2&id=776ec7a95bcb223d03dc55ee525d9a2930af50d8). (thanks to mcs and brade for pointing out the stupid mistake)

comment:16 in reply to:  15 Changed 2 months ago by mcs

Replying to gk:

Okay, okay. Let's actually take bug_27865_v2 (https://gitweb.torproject.org/user/gk/tor-browser-build.git/commit/?h=bug_27865_v2&id=776ec7a95bcb223d03dc55ee525d9a2930af50d8).

This looks good to me now. I don't have access to a Windows system at the moment, but I tried to test the patch in a slightly modified form on macOS (to make sure the configure logic you added is working correctly; that is, to make sure we avoid turning on --enable-release). Unfortunately, there is something unrelated wrong with my build environment right now so I could not complete my experiment.

comment:17 Changed 2 months ago by gk

Richard tested it and it still seems to be crashing. :( I guess I go with the more heavy-handed approach and just disable MOZILLA_OFFICIAL for Windows for 8.5a3.

comment:18 Changed 2 months ago by gk

Keywords: TorBrowserTeam201810R added; TorBrowserTeam201809R removed

Moving review tickets to October

comment:19 in reply to:  17 Changed 2 months ago by gk

Resolution: fixed
Status: needs_reviewclosed

Replying to gk:

Richard tested it and it still seems to be crashing. :( I guess I go with the more heavy-handed approach and just disable MOZILLA_OFFICIAL for Windows for 8.5a3.

That works and I added the patch to master (commit 49eb43da16695c8fce31129f3499a8258761025a).

Note: See TracTickets for help on using tickets.