1486759 - The Mozilla Crash Reporter window is not displayed when using a non-ascii profile

Status: VERIFIED FIXED

(Toolkit :: Crash Reporting, defect)

Description

[Cristian Baica [:cbaica], Release Desktop QA]

Attachment: crash-reporter-bug

[Affected versions]:
- Fx63.0b1
- Fx63.0a1

[Unaffected versions]:
- Fx62.0b20
- Fx62.0

[Affected platforms]:
- Windows 10 x64
- Windows 7 x64

[Steps to reproduce]:
1. Launch Firefox from the command line to reach the 'Choose user profile' window.
2. Create a new profile using non-ascii characters. (e.g. ☻☺☕ճմյµ®).
3. Start Firefox using the created profile.
4. Crash Firefox by typing into the address bar "about:crashparent".

[Expected result]:
- The Mozilla Crash Reporter window is displayed.

[Actual result]:
- The user only receives a warning prompt, informing him of an error that has occurred.

[Regression range]:
- I will look into the regression range as soon as possible.

[Additional notes]:
- This issue seems to be a particularity for the windows environments.
- There is no crash report generated for that profile (about:crashes section is empty).
- Using a profile containing normal characters will have the Mozilla Crash Reporter window correctly displayed.

Comment 1

[Gabriele Svelto [:gsvelto] (PTO)]

This is a known problem, probably caused by bug 1435999.

Comment 2

[Julien Cristau [:jcristau] (back April 22)]

that bug seems old, do you have an explanation for this one apparently only affecting 63?

Comment 3

[Gabriele Svelto [:gsvelto] (PTO)]

(In reply to Julien Cristau [:jcristau] from comment #2)
> that bug seems old, do you have an explanation for this one apparently only
> affecting 63?

That's weird, this should affect all versions. Firefox 63 however ships with a new version of Breakpad, it's possible that the interaction between the code within Firefox and in the crashreporter client changed because of that causing this issue. I'll investigate it ASAP.

Comment 4

[Cristian Baica [:cbaica], Release Desktop QA]

I have managed to narrow it down as follows:
The last good build ID: 20180715220110.
The first bad build ID: 20180716100102.

Comment 5

[Cristian Baica [:cbaica], Release Desktop QA]

https://hg.mozilla.org/mozilla-central/pushloghtml?fromchange=6a320851d377068d46a59ff11d5d5124b219138a&tochange=2ed1506d1dc7db3d70a3feed95f1456bce05bbee

Comment 6

[Julien Cristau [:jcristau] (back April 22)]

bug 1475384 kind of jumps out from that push log.

Comment 7

[Julien Cristau [:jcristau] (back April 22)]

Looping in :dmajor based on comment 5.

Comment 8

[(Away)]

crashreporter.exe's entry point is `main` with lld rather than `wWinMain` that was desired, so extended characters in argv don't survive the translation.

I think this is https://bugs.llvm.org/show_bug.cgi?id=36523

Comment 9

[(Away)]

The LLVM fix was merged into the 7.0.0 release branch post-rc2, we should switch to rc3 when the tag is ready.

Comment 10

[Ryan VanderMeulen [:RyanVM]]

According to llvm.org, the final 7.0.0 release should be today-ish. David, what version of LLVM are we currently using for 63? Now that 63 is on Beta, I'm wondering what the delta is between the final release and whatever version we're currently using. Should we consider just cherry-picking the upstream fix for Beta63?

Comment 11

[(Away)]

The fix depends on previous changesets so it would be annoying to cherry-pick. We're currently on a trunk revision from the first day of 8.0.0. I think it would be useful to move to 7.0.0 rc3 (and refresh again to the final release when available) to get a widely-tested revision and pick up fixes that LLVM considered release-blocking.

Comment 12

[Sylvestre Ledru [:Sylvestre]]

LLVM 7 won't ship today ( http://lists.llvm.org/pipermail/cfe-dev/2018-September/059245.html ). I expect it will ship in 1 or 2 weeks tops.

Comment 13

[Sylvestre Ledru [:Sylvestre]]

Attachment: Bug 1486759 - Cherry pick a lld fix to fix the Windows entry point r?dmajor,glandium

Not waiting for rc3 or final from llvm because the issue is pretty severe

Comment 14

[Sylvestre Ledru [:Sylvestre]]

https://treeherder.mozilla.org/#/jobs?repo=try&revision=45a8d28c084a5547c0aebdf4388fa268e8c69c8e

Comment 15

[(Away)]

Comment on attachment 9006810 [details]
Bug 1486759 - Cherry pick a lld fix to fix the Windows entry point r?dmajor,glandium

David Major [:dmajor] has approved the revision.

Comment 16

[Pulsebot]

Pushed by [e-mail]:
https://hg.mozilla.org/integration/autoland/rev/addfbb3c6167
Cherry pick a lld fix to fix the Windows entry point r=dmajor

Comment 17

[Dorel Luca [:dluca]]

https://hg.mozilla.org/mozilla-central/rev/addfbb3c6167

Comment 18

[Sylvestre Ledru [:Sylvestre]]

Comment on attachment 9006810 [details]
Bug 1486759 - Cherry pick a lld fix to fix the Windows entry point r?dmajor,glandium

Approval Request Comment
[Feature/Bug causing the regression]: bug 1475384
[User impact if declined]: No crash in some context
[Is this code covered by automated tests?]: I don't think but this is linker level stuff. If we didn't break firefox ci, we should be safe.
The change has been in upstream (lld) trunk for about a month.
[Has the fix been verified in Nightly?]: No, I don't have a Windows and the code just landed
[Needs manual test from QE? If yes, steps to reproduce]: See comment #0
[List of other uplifts needed for the feature/fix]: None
[Is the change risky?]: Probably not
[Why is the change risky/not risky?]: Upstream didn't regress with that patch, I think we are good.
[String changes made/needed]: NA

Comment 19

[(Away)]

I didn't test the full scenario with a profile but I confirmed in a debugger that the m-c opt build's entry point is wWinMain.

Comment 20

[Cristian Baica [:cbaica], Release Desktop QA]

Tested the fix using Fx 64.0a1 (buildID: 20180909220130) on Windows 10 x64 and Windows 7 x64. The Mozilla Crash Reporter is now displayed after Mozilla crashes.
Marking as Verified for the Firefox 64 branch and waiting for the fix on beta as well.

Comment 21

[Pascal Chevrel:pascalc (PTO until April 26)]

Comment on attachment 9006810 [details]
Bug 1486759 - Cherry pick a lld fix to fix the Windows entry point r?dmajor,glandium

Uplift approved for 63 beta 5

Comment 22

[Daniel Varga [:dvarga]]

https://hg.mozilla.org/releases/mozilla-beta/rev/151237fbc3d2

Comment 23

[Cristian Baica [:cbaica], Release Desktop QA]

Tested the uplift using the latest beta Fx 63.0b5 on Windows 10 x64, macOS 10.13.6 and Ubuntu 16.04 x86. The Mozilla Crash Reporter window is displayed without any issues and the crash report is generated.
Marking the issue as verified fixed.