TB v4.0 (xul.dll) crashes on Windows

Hi,

I tried out the 4.0 TB bundle today on Windows 7 SP1 64-bit and it consistently crashed after logging into gmail. Gmail would authenticate and the page would begin to load (I could see emails), but when the page load completed, the entire browser crashed. I went back to 3.6.6, which works fine on this machine.

added TorBrowserTeam201410 component::applications/tor browser fuck-mingw owner::tbb-team priority::very high resolution::fixed severity::normal status::closed tbb-crash tbb-helpdesk-frequent type::defect labels

Does this happens somewhere else, too? I don't have a Gmail account, which makes reproducing it hard for me.

Trac:
Version: Tor: unspecified to N/A
Keywords: N/A deleted, tbb-crash added

Replying to gk:

Does this happens somewhere else, too? I don't have a Gmail account, which makes reproducing it hard for me.

There are more "TB crash" tickets on RT. I believe this issue is limited to Windows verson of TB4.0.

Some websites reported by users: tweetdeck chatovod.com

And the error messages: Firefox.exe - EXCEPTION A breakpoint has been reached.

Trac:
Username: Jason

Replying to Jason:

Replying to gk:

Does this happens somewhere else, too? I don't have a Gmail account, which makes reproducing it hard for me.

There are more "TB crash" tickets on RT. I believe this issue is limited to Windows verson of TB4.0.

Some websites reported by users: tweetdeck chatovod.com

And the error messages: Firefox.exe - EXCEPTION A breakpoint has been reached.

I can reproduce that with tweetdeck on a Windows machine. Let me know if OS X and Linux are affected as well with some crashes (tweetdeck works on my Linux box at least). Marking as 'critical' as it is probably affecting a ton of users and the crash reason is unknown yet.

Trac:
Priority: normal to critical
Summary: TB v4.0 crashes onload for gmail to TB v4.0 crashes on Windows

Replying to gk:

I can reproduce that with tweetdeck on a Windows machine. Let me know if OS X and Linux are affected as well with some crashes (tweetdeck works on my Linux box at least). Marking as 'critical' as it is probably affecting a ton of users and the crash reason is unknown yet.

Didn't see any crash complaints about OS X and Linux. Now I'm directing users to this ticket and ask them to add more details.

Trac:
Username: Jason

Problem Event Name: APPCRASH Application Name: firefox.exe Application Version: 31.2.0.0 Application Timestamp: 00000000 Fault Module Name: xul.dll Fault Module Version: 31.2.0.0

Windows 7 64bit, clean TBB4 install. Suspect jquery on page is involved.

Trac:
Username: u0

Don't know why, but looks like it works (at least for tweetdeck crahs).

Here it is:

1. Click NoScript and choose "Forbid scripts globally";
2. Click NoScript, then choose Option > Embeddings;
3. In the "addtional restrictions for untrusted sites" section, check all the options;
4. Open "https://tweetdeck.twitter.com/";
5. When it begins to load the page, click Noscript and choose "temporarily allow all this page";
6. If the page keeps loading like forever, click "refresh" or press F5.

Trac:
Username: Jason

Trac:
start.cmd

Disable trap to debugger

Useless, xul.dll contains unknown code, no such code in repos exist.

My full-fledged debug build crashes on Windows way earlier for different reasons (will be a new issue to investigate) and the default build gives the attached debug log. Seems we need some symbols here. I am building a new debug build just with debug symbols and deoptimized code. Might already be enough to find the problem.

Trac:
Debug.TXT

debug information -- crash with default build

My original comment was this one: "My TBB keeps crashing every time I try to read my Gmail emails. No idea why. On Win 7, 32-bit. Everything worked perfectly before on the alphas 4.0 1,2, and 3. :("

TBB 4.0 is still crashing on my Win7 machine (initially in GMail but now also in the same way when I tried to register to make this comment, haha). However it's working fine on my Mac 64bit with Yosemite installed, GMail included.

Hope this helps and a big thank you to everyone like yourselves who puts effort in to make everything work.

Trac:
Username: belinda

Marked #13457 (moved) duplicate.

Marked #13468 (moved) as duplicate. oboom.com is affected as well.

Marked #13492 (moved) as duplicate.

Trac:
Cc: N/A to Sherief

Confirmed on Windows using a gmail account.

Crash log:

Problem signature:
  Problem Event Name:	APPCRASH
  Application Name:	firefox.exe
  Application Version:	31.2.0.0
  Application Timestamp:	00000000
  Fault Module Name:	xul.dll
  Fault Module Version:	31.2.0.0
  Fault Module Timestamp:	00000000
  Exception Code:	80000003
  Exception Offset:	0105d1e4
  OS Version:	6.1.7601.2.1.0.256.48
  Locale ID:	1033
  Additional Information 1:	0a9e
  Additional Information 2:	0a9e372d3b4ad19135b953a78882e789
  Additional Information 3:	0a9e
  Additional Information 4:	0a9e372d3b4ad19135b953a78882e789

Trac:
Cc: Sherief to N/A

This seems not to be caused by our patches. A vanilla ESR 31.2.0 compiled with mingw-w64 is crashing as well. And it does not seem to be a compiler bug either as Tor Browser compiled with mingw-w64 based on GCC 4.8.3 is crashing, too. Trying to bisect ESR 31 itself now to find the culprit.

Trac:
Cc: N/A to Sherief

My Tor Browser 4.0 crashes if I try to open local or online mp3 files. Logs show xul.dll

Another one has reported the same issue on the blog comments.

I didn't find any problems with OS X.

Could it be about the new hardening? #10065 (moved)

Trac:
Keywords: N/A deleted, tbb-helpdesk-frequent, TorBrowserTeam201410 added

Replying to cypherpunks:

Could it be about the new hardening? #10065 (moved)

Good idea but alas it is not that easy. Compiling without hardening is still crashing Tor Browser.

Replying to gk:

And it does not seem to be a compiler bug either as Tor Browser compiled with mingw-w64 based on GCC 4.8.3 is crashing, too. Tor Browser compiled with d6435c83fe7268ef479f2db7cfd145684a9ffcc2 commit reverted or just with older GCC?

Replying to cypherpunks:

Replying to gk:

And it does not seem to be a compiler bug either as Tor Browser compiled with mingw-w64 based on GCC 4.8.3 is crashing, too. Tor Browser compiled with d6435c83fe7268ef479f2db7cfd145684a9ffcc2 commit reverted or just with older GCC?

Just an older GCC as the mingw tag is too old for compiling Firefox ESR 31.

Replying to gk:

A vanilla ESR 31.2.0 compiled with mingw-w64 is crashing as well.

With disabled webrtc?

Resolved #13532 (moved) as duplicate.

Trac:
Cc: Sherief to Sherief, user523

Nothing

Nothing

As an additional data point: Firefox 30 is crashing, too, but not 28.0a1 (built from rev 155018). This is basically with the Tor Browser .mozconfig (only webgl and accessibility disabled to speed things up).

Trac:
Cc: Sherief, user523 to Sherief, user523, arthuredelstein

Replying to cypherpunks:

Try Hotfix: set media.directshow.enabled pref to false.

I tried this and fixes tweetdeck crash. What does it do? Does it compromize anonimity?

Trac:
Username: bullgeschichte

What does it do?

It disable DirectShow to playback mp3 and another patented coding formats.

Does it compromize anonimity?

Probably. See #13543 (moved)

Trac:
Summary: TB v4.0 crashes on Windows to TB v4.0 (xul.dll) crashes on Windows

Can anybody to share (high level compressed) xull.dll for Tor Browser compiled with usual .mozconfig but webrtc enabled?

Resolved #13549 (moved) as a duplicate.

Trac:
Cc: Sherief, user523, arthuredelstein to Sherief, user523, arthuredelstein, sepand

gk - I am reluctant to call the pref change a workaround that we want to make a release for, unless it seems unlikely for us to find a better solution in a reasonable time frame. How is the bisecting going? Think you're likely to find an offending commit between now and the meeting on Monday?

Replying to cypherpunks:

Can anybody to share (high level compressed) xull.dll for Tor Browser compiled with usual .mozconfig but webrtc enabled?

Alas, no, as compiling WebRTC with mingw-w64 is broken at the moment.

Replying to mikeperry:

gk - I am reluctant to call the pref change a workaround that we want to make a release for, unless it seems unlikely for us to find a better solution in a reasonable time frame. How is the bisecting going? Think you're likely to find an offending commit between now and the meeting on Monday?

Tricky, I am close (last good rev 158433, first bad rev 159183) but it does not go faster as the breakage and amount of custom patches which need to get applied to get it built at all is rising. I might be lucky with some educated guesses today, we'll see. But given that I am afk from Sunday - Wednesday inclusive am not so optimistic.

(last good rev 158433, first bad rev 159183)

It's probably about enabling DirectShow for mp3 in Vista+ since 28 version then, because you testing using Win7 (?). Firefox disabled DirectShow for mp3 in Vista+ since 27 version.

Resolved #13559 (moved) as a duplicate.

Trac:
Cc: Sherief, user523, arthuredelstein, sepand to Sherief, user523, arthuredelstein, sepand, samskarebyaha

Replying to cypherpunks:

(last good rev 158433, first bad rev 159183)

It's probably about enabling DirectShow for mp3 in Vista+ since 28 version then, because you testing using Win7 (?). Firefox disabled DirectShow for mp3 in Vista+ since 27 version.

Yes. It turns out the crash is reproducible since the DirectShow code landed: https://hg.mozilla.org/mozilla-central/rev/e7fef018f421 is the first revision that breaks the build.

Okay, this is now https://bugzilla.mozilla.org/show_bug.cgi?id=1088848.

So what's next? Is it just a case of waiting for Mozilla to patch this?

Trac:
Username: u0

Firefox and mingw are incompatible. Mozilla not even finished to code proper support of mingw, and they builds using MSVC for windows. What purpose to base Tor Browser on software that was designed for M$ and with every new feature even more close to M$?

Did all forget about cookie management?

Trac:
Username: user523

I can also reproduce this issue.

The current workaround is going to about:config and changing media.directshow.enabled to false as said here: https://bugzilla.mozilla.org/show_bug.cgi?id=1088848

Thanks to gk for sharing the link in comment 40.

This is a very annoying bug and it should be either fixed or have the above workaround applied.

Trac:
Username: NewEraCracker

Nothing