Tor Browser for Windows is borked with hardware acceleration enabled (because of gcc?)

Podpis problému: Název události problému: APPCRASH Název aplikace: firefox.exe Verze aplikace: 17.0.6.0 Časové razítko aplikace: 386d4380 Název chybného modulu: d2d1.dll Verze chybného modulu: 6.1.7601.17514 Časové razítko chybného modulu: 4ce7b7aa Kód výjimky: c0000005 Posun výjimky: 0001f3ba Verze operačního systému: 6.1.7601.2.1.0.256.1 ID národního prostředí: 1029 Další informace 1: 0a9e Další informace 2: 0a9e372d3b4ad19135b953a78882e789 Další informace 3: 0a9e Další informace 4: 0a9e372d3b4ad19135b953a78882e789

Přečtěte si prohlášení o zásadách ochrany osobních údajů online: http://go.microsoft.com/fwlink/?linkid=104288&clcid=0x0405

Pokud není k dispozici Prohlášení o zásadách ochrany osobních údajů online, přečtěte si toto prohlášení offline: C:\Windows\system32\cs-CZ\erofflps.txt

Trac:
Username: dope457

added TorBrowserTeam201807R in Legacy / Trac component::applications/tor browser in Legacy / Trac ff60-esr in Legacy / Trac fuck-mingw in Legacy / Trac owner::tbb-team in Legacy / Trac priority::high in Legacy / Trac reporter::dope457 in Legacy / Trac resolution::fixed in Legacy / Trac severity::normal in Legacy / Trac status::closed in Legacy / Trac tbb-crash in Legacy / Trac type::defect in Legacy / Trac labels

Seems still to be an issue with TBB based on Firefox ESR 24. See: legacy/trac#10531 (closed).

See: legacy/trac#11943 (closed) Disabling of direct2d and acceleration doesn't help.

Trac:
Version: Tor: unspecified to N/A
Milestone: Tor: unspecified to N/A

This ticket is still open.

Is this the one that we fixed in TBB 3.5rc1? https://blog.torproject.org/blog/tor-browser-bundle-35rc1-released "Misc Prefs: Disable layer acceleration to avoid crashes on Windows"

Or was that some other ticket?

Replying to arma:

This ticket is still open.

Is this the one that we fixed in TBB 3.5rc1? https://blog.torproject.org/blog/tor-browser-bundle-35rc1-released "Misc Prefs: Disable layer acceleration to avoid crashes on Windows"

Or was that some other ticket?

No, this one, thanks.

Trac:
Status: new to closed
Resolution: N/A to fixed

Started experiencing this bug with an old(ish) install; updated to latest public version (3.6.3) and still crashes.

Workarounds discussed in https://lists.torproject.org/pipermail/tor-talk/2013-June/028564.html work.

I updated my NVidia drivers a couple of weeks ago which is possibly the cause. Currently running 340.52, Direct3D v11 on a GeForce GTX 770. Windows 7 Pro 64-bit.

Trac:
Username: christopher

Trac:
Username: christopher
Status: closed to reopened
Resolution: fixed to N/A

Workarounds discussed in ​https://lists.torproject.org/pipermail/tor-talk/2013-June/028564.html work. XP Compatible mode? Or you changes prefs yet? gfx.direct2d.disabled and layers.acceleration.disabled should be set true by default, what they are in your crashing browser?

Trac:
Component: Tor bundles/installation to Tor Browser
Status: reopened to needs_information

Fuck windows, mingw, and everything near it.

Trac:
Severity: N/A to Normal
Sponsor: N/A to N/A

Fuck windows, mingw, and everything near it.

Fuck windows, mingw, and everything near it.

Fuck windows, mingw, and everything near it.

Trac:
Summary: TBB 3.0a1 crashes on startup on Win7 (TorBrowser has stopped working) to Cross compile for windows is borked because mingw, gcc, and Win32 ABI
Keywords: firefox-crash, tbb-3.0 deleted, cross-compile added

Fuck windows, mingw, and everything near it.

Trac:
Summary: Cross compile for windows is borked because mingw, gcc, and Win32 ABI to Tor Browser for windows is borked because mingw, gcc, and Win32 ABI

Trac:
Keywords: cross-compile deleted, N/A added

Trac:
Cc: N/A to mcs
Owner: erinn to tbb-team
Status: needs_information to assigned

Trac:
Status: assigned to needs_information

Trac:
Status: needs_information to new

Fuck windows, mingw, and everything near it.

Fuck windows, mingw, and everything near it.

Fuck windows, mingw, and everything near it.

Fuck windows, mingw, and everything near it.

Trac:
Keywords: N/A deleted, Hardware acceleration, ABI, GCC, Windows added

Fuck windows, mingw, and everything near it.

Fuck windows, mingw, and everything near it.

Trac:
Keywords: Hardware acceleration deleted, Hardware-acceleration added

Trac:
Keywords: N/A deleted, mingw added

Trac:
Keywords: mingw deleted, fuck-mingw added

Trac:
Summary: Tor Browser for windows is borked because mingw, gcc, and Win32 ABI to TBB 3.0a1 crashes on startup on Win7
Keywords: ABI, GCC deleted, N/A added

Fuck windows, fuck mingw, and fuck everything near it.

Looking at this f*ck-mingw bug, the GCC ticket (this is actually a GCC bug it seems) is: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64384.

Trac:
Reviewer: N/A to N/A

To add some explicit instructions here as this gets referenced often. For a built browser suffering from the problem, on Windows:

1. Copy browser/omni.ja twice, once to omni.ja-backup and once to omni.zip
2. Unzip the zip file using Windows built-in Zip Extractor. ([0] Indicates that other zip programs will not work correctly)
3. In the extracted omni/ folder, edit default/preferences/firefox.js and add pref("gfx.direct2d.disabled",true);
4. Repackage the folder by running (in the extracted omni/ folder) zip -qr9XD omni.ja * - I used the cygwin zip package to do this. [0] indicates that other packaging methods will not work.
5. move the repackages omni.ja over top the original (you have the back up right?!) and test!

I was able to get it running with only gfx.direct2d.disabled - maybe one might need the layers.acceleration.disabled set to true too?

[0] https://developer.mozilla.org/en-US/docs/Mozilla/About_omni.ja_%28formerly_omni.jar%29

Do we really need to enable direct access to hardware for the browser? Current prefs look pretty well:

Decision Log
HW_COMPOSITING	
disabled by user: Disabled by pref
D3D11_COMPOSITING	
unavailable by default: Hardware compositing is disabled
D3D9_COMPOSITING	
unavailable by default: Hardware compositing is disabled
DIRECT2D	
unavailable by default: Direct2D requires Direct3D 11 compositing
D3D11_HW_ANGLE	
unavailable by default: D3D11 compositing is disabled
disabled by env: D3D11 compositing is disabled

Trac:
Summary: TBB 3.0a1 crashes on startup on Win7 to Tor Browser for Windows is borked with hardware acceleration enabled (because of gcc?)
Keywords: Hardware-acceleration, Windows deleted, N/A added

FWIW: tjr is fighting with that over at Mozilla, see: https://bugzilla.mozilla.org/show_bug.cgi?id=1411401.

legacy/trac#25209 (moved) is likely a duplicate.

https://bugzilla.mozilla.org/show_bug.cgi?id=1411401#c24 is relevant. As we still have users hitting this bug we could think about solving it as Jacek mentioned, especially as I moved to the current mingw-w64 commit to get this fix for free (I did not realize that this was not the case).

Trac:
Keywords: N/A deleted, ff60-esr added
Cc: mcs to mcs, sukhbir

For review:

tor-browser-build (sets the CXXFLAGS):

https://github.com/azadi/tor-browser-build-1/tree/bug-9145

Tor Browser (removes the preferences):

https://github.com/azadi/gecko-dev/tree/bug-9145

I tested this on a Windows machine with an earlier build and Tor Browser was indeed crashing when the preferences were enabled (set to false). The new build with the above change does not crash; I verified this for both the 32- and 64-bit versions of Tor Browser.

Trac:
Status: new to needs_review

Trac:
Cc: mcs, sukhbir to mcs, sukhbir, jllover

Marked legacy/trac#26423 (moved) as duplicate.

Trac:
Keywords: N/A deleted, TorBrowserTeam201806R added

Moving reviews to July.

Trac:
Keywords: TorBrowserTeam201806R deleted, TorBrowserTeam201807R added

Would it be enough to just have CXXFLAGS="-DWIDL_EXPLICIT_AGGREGATE_RETURNS" instead of CXXFLAGS="$CXXFLAGS -DWIDL_EXPLICIT_AGGREGATE_RETURNS"? I wonder if we should do an export CXXFLAGS instead of just a CXXFLAGS as Mozilla is doing it in the cross-compile macOS mozconfig, to pass down the flags to the various parts of the build system.

Replying to gk:

Would it be enough to just have CXXFLAGS="-DWIDL_EXPLICIT_AGGREGATE_RETURNS" instead of CXXFLAGS="$CXXFLAGS -DWIDL_EXPLICIT_AGGREGATE_RETURNS"? I wonder if we should do an export CXXFLAGS instead of just a CXXFLAGS as Mozilla is doing it in the cross-compile macOS mozconfig, to pass down the flags to the various parts of the build system.

OK I updated it to export CXXFLAGS instead and also rebased it on the respective HEAD commits.

Tor Browser build:

https://github.com/azadi/tor-browser-build-1/tree/bug-9145-rev1

Tor Browser (should this have been a fixup commit perhaps?):

https://github.com/azadi/gecko-dev/tree/bug-9145

Replying to sukhbir:

Tor Browser (should this have been a fixup commit perhaps?):

Yes, please. You could add some more info doing a git commit --amend, so that everyone can later on look at tor-browser-60.1.0esr-8.0-1 to find out why the prefs are gone now (i.e. before the rebase happens and the fixup commit vanishes).

Trac:
Status: needs_review to needs_revision
Keywords: TorBrowserTeam201807R deleted, TorBrowserTeam201807 added

https://github.com/azadi/tor-browser-build-1/tree/bug-9145-rev1

https://github.com/azadi/gecko-dev/tree/bug-9145-rev2

Trac:
Status: needs_revision to needs_review

Trac:
Keywords: TorBrowserTeam201807 deleted, TorBrowserTeam201807R added

Thanks, pushed to tor-browser-build master (commit 11e0e597480bbbd03410431107b26b0492c4fd83) and cherry-picked onto tor-browser-60.1.0esr-8.0-1 (commit 83eaa009).

Trac:
Status: needs_review to closed
Resolution: N/A to fixed

HWA of everything by default?! Without security/fingerprintability analysis?!

Trac:
Username: dumbacc