1566855 - about:crashes lists unsubmittable reports with missing .extra files

Status: RESOLVED FIXED

(Toolkit :: Crash Reporting, defect)

Description

[Selim Şumlu]

I have two crash reports that Nightly failed to submit automatically since yesterday.

If I go to about:crashes and manually click "Submit", it instantly says "Failed".

I don't see any updates in the browser console while trying to manually submit a report.

I have a number of crash reports submitted successfully before yesterday.

Any idea why this could be happening or how to triangulate the issue?

Comment 1

[Marcia Knous [:marcia]]

Hello Eric - Any idea who else might be able to answer Selim's question since Gabriele is out? Thanks in advance.

Comment 2

[Eric Rahm [:erahm]]

I think unfortunately the answer is nobody. With ted gone, I'd ask froydnj, but he's out until next week. It looks like Osmose was familiar with about:crashes, but he's gone as well. Alexis Deschamps worked on it as well, but is gone. Will KG possibly could have helped but is out on PTO as well.

mconley it looks like you at least reviewed about:crashes code recently, do you have any pointers for Selim?

Comment 3

[Mike Conley (:mconley) (:⚙️)]

Hi Selim,

You mention that there's nothing in the Browser Console - but if you open up the Developer Toolbox on the about:crashes page, is there anything there in the Web Console that might look related?

Comment 4

[Selim Şumlu]

(In reply to Mike Conley (:mconley) (:⚙️) from comment #3)

Hi Selim,

You mention that there's nothing in the Browser Console - but if you open up the Developer Toolbox on the about:crashes page, is there anything there in the Web Console that might look related?

No, there's no output at all.

Comment 5

[Mike Conley (:mconley) (:⚙️)]

Thanks, Selim.

How familiar are you with the JavaScript debugger in the Firefox DevTools? If you're feeling adventurous, you could try setting a breakpoint in crashes.js here:

https://searchfox.org/mozilla-central/rev/4fbcfe6fecf75d7b828fbebda79a31385f7eab5f/toolkit/crashreporter/content/crashes.js#146

and stepping through to see where things fall over. If you've not got the time to do that, I could send you a prepared build with some instrumentation that might help us figure out what's going on - but stepping through with the debugger might be faster if you have the time.

Comment 6

[Selim Şumlu]

Unfortunately I have no experience working with the debugger. A prepared build might be a better way to move foreward.

Comment 7

[Andrew McCreight [:mccr8]]

Do you have Fission enabled?

Comment 8

[Selim Şumlu]

(In reply to Andrew McCreight [:mccr8] from comment #7)

Do you have Fission enabled?

No, I don't. Everything related to fission in about:config is set to false.

Comment 9

[Mike Conley (:mconley) (:⚙️)]

I just realized that I also have a crash report in about:crashes that I can't submit. Perhaps we're hitting the same bug.

I used the Browser Toolbox debugger, and found out that my instance of Firefox Nightly is bailing out here. This is because extraExists is false.

Selim, I have a request - can you please note the IDs of the crash reports that you can't send in about:crashes, and paste them in a comment here. Then, can you please do the following:

1. Open the Web Developer Toolbox (App Menu > Web Developer > Toggle Tools)
2. Click on the 3 dots (...) near the X on the right side of the toolbox, and click "Settings"
3. Under "Advanced Settings", make sure "Enable browser chrome and add-on debugging toolboxes" is checked
4. Open the Browser Console, which should now have a line for inputting things.

Paste the following into the Browser Console:

{
  let uAppDataPath = Services.dirsvc.get("UAppData", Ci.nsIFile).path;
  let reportsDir = OS.Path.join(uAppDataPath, "Crash Reports", "pending");
  let iterator = new OS.File.DirectoryIterator(reportsDir);
  iterator.forEach(entry => {
    console.log(entry.path);
  });
}

What that will do is log all of the files in the pending crashes directory. Can you copy those log messages and paste those in here, along with the ID of the crashes that you can't submit?

Comment 10

[Selim Şumlu]

Report IDs:
35c4c8ed-02e7-428a-a388-a51e773e88aa
b6838da9-783c-41e5-931c-520ab6f74476

Browser console output:

NS_NOINTERFACE: Component returned failure code: 0x80004002 (NS_NOINTERFACE) [nsISupports.QueryInterface] 2 stack-trace-collector.js:90
C:\Users\Selim\AppData\Roaming\Mozilla\Firefox\Crash Reports\pending\02c896c6-5afd-4e58-a396-d4aad881f840-browser.dmp debugger eval code:6:13
C:\Users\Selim\AppData\Roaming\Mozilla\Firefox\Crash Reports\pending\33901c51-03c4-4298-b157-d75f1f90f560-browser.dmp debugger eval code:6:13
C:\Users\Selim\AppData\Roaming\Mozilla\Firefox\Crash Reports\pending\35c4c8ed-02e7-428a-a388-a51e773e88aa.dmp debugger eval code:6:13
C:\Users\Selim\AppData\Roaming\Mozilla\Firefox\Crash Reports\pending\443dce58-10fa-4b86-8f81-f42b78dfff63-browser.dmp debugger eval code:6:13
C:\Users\Selim\AppData\Roaming\Mozilla\Firefox\Crash Reports\pending\4473c31e-27c8-4404-bd26-58ccbbd914ec-browser.dmp debugger eval code:6:13
C:\Users\Selim\AppData\Roaming\Mozilla\Firefox\Crash Reports\pending\47940ff3-f9dd-4e63-a013-da99dacac286-browser.dmp debugger eval code:6:13
C:\Users\Selim\AppData\Roaming\Mozilla\Firefox\Crash Reports\pending\49d215ec-f84a-4bfe-bef6-36316a4879d3-browser.dmp debugger eval code:6:13
C:\Users\Selim\AppData\Roaming\Mozilla\Firefox\Crash Reports\pending\53ae3eaa-4018-4053-b3d6-7a6e86285b3c-browser.dmp debugger eval code:6:13
C:\Users\Selim\AppData\Roaming\Mozilla\Firefox\Crash Reports\pending\62646c11-9408-4fd7-a538-e8c4504765ab-browser.dmp debugger eval code:6:13
C:\Users\Selim\AppData\Roaming\Mozilla\Firefox\Crash Reports\pending\6c7d5be4-3e95-4b42-b499-5f4dcc57dcc1-browser.dmp debugger eval code:6:13
C:\Users\Selim\AppData\Roaming\Mozilla\Firefox\Crash Reports\pending\705c890b-3ff0-4eb1-a187-4b6aaa1cb913-browser.dmp debugger eval code:6:13
C:\Users\Selim\AppData\Roaming\Mozilla\Firefox\Crash Reports\pending\723dd99c-2c5d-46de-adac-40ff94282703-browser.dmp debugger eval code:6:13
C:\Users\Selim\AppData\Roaming\Mozilla\Firefox\Crash Reports\pending\77d28e55-fe12-4df5-9fb2-ac0fcae8689c-browser.dmp debugger eval code:6:13
C:\Users\Selim\AppData\Roaming\Mozilla\Firefox\Crash Reports\pending\7f786ce5-48b5-4c4b-85b9-a5879aae3004-browser.dmp debugger eval code:6:13
C:\Users\Selim\AppData\Roaming\Mozilla\Firefox\Crash Reports\pending\81719588-0889-4c38-8910-413620436a6b-browser.dmp debugger eval code:6:13
C:\Users\Selim\AppData\Roaming\Mozilla\Firefox\Crash Reports\pending\885d1435-6551-4130-a034-d404bb4ca1a7-browser.dmp debugger eval code:6:13
C:\Users\Selim\AppData\Roaming\Mozilla\Firefox\Crash Reports\pending\8dbe49a8-a3a4-47ba-b88c-3d1482c38d85-browser.dmp debugger eval code:6:13
C:\Users\Selim\AppData\Roaming\Mozilla\Firefox\Crash Reports\pending\8e1e4b06-7c3d-4ceb-9432-3c456552ab46-browser.dmp debugger eval code:6:13
C:\Users\Selim\AppData\Roaming\Mozilla\Firefox\Crash Reports\pending\9cf14883-f2d2-460f-b560-3bae68a1075e-browser.dmp debugger eval code:6:13
C:\Users\Selim\AppData\Roaming\Mozilla\Firefox\Crash Reports\pending\b6838da9-783c-41e5-931c-520ab6f74476.dmp debugger eval code:6:13
C:\Users\Selim\AppData\Roaming\Mozilla\Firefox\Crash Reports\pending\c7cf0f65-601d-4846-a638-549844bc07c1-browser.dmp debugger eval code:6:13
C:\Users\Selim\AppData\Roaming\Mozilla\Firefox\Crash Reports\pending\c8ccab11-3dda-4215-b936-d653aee90edd-browser.dmp debugger eval code:6:13
C:\Users\Selim\AppData\Roaming\Mozilla\Firefox\Crash Reports\pending\ca6a30ca-2402-4ba0-9486-45127ae94fda-browser.dmp debugger eval code:6:13
C:\Users\Selim\AppData\Roaming\Mozilla\Firefox\Crash Reports\pending\cb8d8304-bebd-48c3-a89a-d3924df81cf7-browser.dmp debugger eval code:6:13
C:\Users\Selim\AppData\Roaming\Mozilla\Firefox\Crash Reports\pending\ce276664-a854-4299-b69f-7ae0981cc204-browser.dmp debugger eval code:6:13
C:\Users\Selim\AppData\Roaming\Mozilla\Firefox\Crash Reports\pending\d6f10e71-4880-4cec-8b5f-3cad113655b1-browser.dmp debugger eval code:6:13
C:\Users\Selim\AppData\Roaming\Mozilla\Firefox\Crash Reports\pending\e12bd4ab-6c93-4c00-ac88-28b36ae1a8f0-browser.dmp debugger eval code:6:13

Comment 11

[Mike Conley (:mconley) (:⚙️)]

Okay, thank you Selim. I've updated the bug summary to better reflect the problem here.

I guess I have two questions for gsvelto when he is available:

1. Can we assume that .dmp files without .extra files are not something that Soccorro will submit? If so, is there any point in listing crashes without their .extra files in about:crashes?

2. Is there a known issue where .extra files won't be written? I suppose that's really the root cause here, and the failure to submit in about:crashes is more of a symptom.

Comment 12

[Ted Campbell [:tcampbell]]

I'm experience the same issues. One thing I see in my profile directory is that the crashes that are failing have an empty .dmp.ignore file created beside them. The actual dump files are then approx 500kB while normal crash files in the directory are approx 2500kB.

Comment 13

[Mike Conley (:mconley) (:⚙️)]

The .ignore files are likely a red herring. Those files are used to indicate which crash dumps the user has chosen to not submit via the Unsubmitted Crash Report notification bar that we show shortly after startup on Nightly. It shouldn't have any impact on being able to submit via about:crashes (I don't think about:crashes pays any attention to the .ignore files).

tcampbell, do you have .extra files for the crash reports that you can't submit?

Comment 14

[Ted Campbell [:tcampbell]]

No .extra files anywhere in \AppData\Roaming\Mozilla\Firefox\Crash Reports. I have a few dozen successfully submitted .dmp files that are still in the pending directory.

Comment 15

[Eric Rahm [:erahm]]

Just for some extra data points: there was a .extra file refactoring in 68 that could be a possible regression (bug 1547698), also we're working on improving .extra file generation and handling in bug 1420363.

Comment 17

[Mike Conley (:mconley) (:⚙️)]

[Tracking Requested - why for this release]:

This might prevent some crash reports from being submitted to Mozilla, which can hamper our ability to improve stability and catch crash regressions.

Assuming that this is maybe related to the work that took place in bug 1547698, I'll note that those patches landed in Firefox 68, and so both Beta and Release might already be affected.

Comment 18

[Eric Rahm [:erahm]]

We'd like to figure out how bad things are right now. Will, is there any way to tell on the socorro side if our crash volume has dropped significantly? Particularly we're thinking this would affect content process crash reports.

Comment 19

[Will Kahn-Greene [:willkg] ET needinfo? me]

We keep track of the total number of incoming crash reports to the collector and which throttle rule they trigger. We have a throttle rule for "this is firefox desktop release channel". I'll attach a screenshot of that dashboard graph covering the last 3 months. I don't see any "HOLY CRAP--WE'RE ALL DOOMED" dips in it, but it's hard to conclude anything from it.

Socorro does have dashboards in the signature report. Philipp mentioned these two links:

• https://crash-stats.mozilla.com/signature/?product=Firefox&release_channel=nightly&process_type=content&signature=IPCError-browser%20%7C%20ShutDownKill&date=%3E%3D2019-01-24T20:05:00.000Z&date=%3C2019-07-24T20:05:00.000Z#graphs
• https://crash-stats.mozilla.com/signature/?release_channel=nightly&process_type=content&product=Firefox&signature=OOM%20|%20small&date=%3E%3D2019-01-01T00:00:00.000Z&date=%3C2019-07-24T19:59:00.000Z#graphs

If that doesn't suffice, you can use facets with Supersearch API to build a dataset and then graph that. For example, this url shows total crashes by version for today:

https://crash-stats.mozilla.org/api/SuperSearch/?_results_number=0&product=Firefox&date=%3E%3D2019-07-23T00%3A00%3A00.000Z&date=%3C2019-07-24T23%3A59%3A00.000Z&_facets=version

If you string a bunch of those together, you could see dips by version. However, the total crashes numbers are not normalized by anything, so there are lots of caveats with that data.

Comment 20

[Will Kahn-Greene [:willkg] ET needinfo? me]

Attachment: Screenshot_2019-07-24 socorro prod megamaster remix Datadog.png

This picture is pretty, but not really good for screenshots.

The top purple line is "is_firefox_desktop" which is the rule triggered by crash reports for Firefox desktop release channel.

The next one down is yellow and is "infobar_is_true" which is this whole other thing and probably not interesting.

The next two are intertwined. One is "is_alpha_beta_esr" which covers alpha, beta, and esr channels for all products. The other is "accepts_everything". I had to look that one up because wat?! That's an accept anything that doesn't get accepted/rejected by any of the other rules. I don't know what falls into that boat. It's probably non-Firefox things, though.

Comment 21

[Eric Rahm [:erahm]]

Thanks Will, that's pretty helpful! Given our crash volume hasn't drastically dropped I think we're okay waiting to pursue this further until Gabriele returns next week.

Comment 22

[Gabriele Svelto [:gsvelto]]

Back from PTO, I'll try to look into this ASAP. As a rule of thumb we don't submit crash reports w/o .extra files and - barring unlikely issues such as disk-space exhaustion - we should always generate both. Bug 1547698 changed how we write out .extra files by consolidating all the writing in one place. Previously we wrote the .extra file in 3 or 4 different places so if one of the codepaths failed to execute we might still end up with an .extra file (albeit incomplete). With the more stricter code we have now it's possible that we don't write it out at all.

It would be interesting to see what processes the minidump's belong to. Selim could you send me the minidump files that are missing the .extra files via e-mail? They might contain private data so I don't recommend attaching them here.

Comment 23

[Selim Şumlu]

(In reply to Gabriele Svelto [:gsvelto] from comment #22)

It would be interesting to see what processes the minidump's belong to. Selim could you send me the minidump files that are missing the .extra files via e-mail? They might contain private data so I don't recommend attaching them here.

I've just sent you the files by email.

Comment 24

[Selim Şumlu]

I should also let you know that b6838da9-783c-41e5-931c-520ab6f74476 is related to bug 1563801. It was a crash I had on Netflix.

Comment 25

[Gabriele Svelto [:gsvelto]]

Thanks Selim. I manually generated the signature for b6838da9-783c-41e5-931c-520ab6f74476 and filed it under bug 1570950. I hadn't seen you had opened a bug yet so maybe I'll dupe it against the bug you opened. The other crash is also a content process crash and specifically it's bug 1566310. The fact that you didn't have .extra files for those is worrysome. I'll leave this bug open until I investigate what's going on. If you encounter more crashes like this please report them too.

Comment 26

[Gabriele Svelto [:gsvelto]]

Scratch what I said in the comment before. b6838da9-783c-41e5-931c-520ab6f7447 is not bug 1563801, the signature is different so I'll leave it under bug 1570950.

Comment 27

[Gabriele Svelto [:gsvelto]]

I just noticed something very, very worrysome. I have six child process crashes w/o the .extra file in my pending dir. From yesterday night. What's really scary is that the signature corresponds to a change I know has landed recently and there's no hits on crash-stats so we're most likely missing crash reports. I have to revert or fix bug 1547698 ASAP.

Comment 28

[Gabriele Svelto [:gsvelto]]

Quick update: I just managed to repro by crashing content processes while static preferences are being initialized. I should be able to devise a fix by tonight.

Comment 29

[Ryan VanderMeulen [:RyanVM]]

Tentatively tracking this for 68 as a regression from bug 1547698. If the fix ends up being low-risk, we should probably consider taking this in the 68.0.2 dot release coming soon.

Comment 30

[Gabriele Svelto [:gsvelto]]

Further digging revealed that there's two aspects to this issue:

• The first is a known race in the crash reporter code. If a content process crashes early during startup the correspoding CrashReporterHost object hasn't been created yet and we can't finalize the crash report. This is a known problem and all the crashes here are early content process startup crashes.

• The second issue is that the .dmp file for the crashes which couldn't be completed is still around after the crash handling code has done its job. It's possible - and I'm trying to verify it - that before bug 1547698 we silently deleted the .dmp file so we were also losing those crashes but we wouldn't see them at all.

The upside is that we aren't losing any crashes we weren't already losing before, which explains why the crash rate is unaffected.

Comment 31

[Gabriele Svelto [:gsvelto]]

I made some tests on versions prior to bug 1547698 and discovered a couple more things that I hadn't considered. When we encountered an early content process crash besides the minidump we would write part of the .extra file because the process was split among three different pieces of code. Since the CrashReporterHost object had not been instanced yet the .extra file would not be completed and the user would not be notified of the crash. Here's the interesting bit: since the incomplete .extra file existed Firefox would detect the unsubmitted crash the next time it would be launched and prompted the user to submit it. It's possible that Socorro accepted these crash reports but even if it did they would be mis-categorized because they were not labelled as content process crashes (and they were missing more important information). This brings to mind bug 1282776 which I never figured out and which was precisely this issue: early crashes of child processes (plugins in that case) that were mislabeled and incomplete.

So how do we solve it? One possibility is to instance the CrashReporterHost right away when we launch a child process and use ::RecvInitCrashReporterHost() only to add the missing bits (namely the main thread ID and the shmem segment we use for passing crash annotations). This way if a crash happens before ::RecvInitCrashReporterHost() we'll be able to partially complete it and submit it. Some annotations will be missing but it will be still a lot better than the current situation.

There's only a very annoying wrinkle in this plan: different child process types implement ::RecvInitCrashReporterHost() in a different place. Content, GMP, Socket and RemoteSandboxBroker processes implement it in the parent object; VR, GPU and RDD do it in the child. That's something I knew for some time and now I'm forced to deal with it. sigh

Comment 32

[Nathan Froyd [:froydnj]]

(In reply to Gabriele Svelto [:gsvelto] from comment #31)

There's only a very annoying wrinkle in this plan: different child process types implement ::RecvInitCrashReporterHost() in a different place. Content, GMP, Socket and RemoteSandboxBroker processes implement it in the parent object; VR, GPU and RDD do it in the child. That's something I knew for some time and now I'm forced to deal with it. sigh

Note that, for reasons, GPU (and I believe VR and RDD, who used GPU as a template) processes have the child and parent terminology reversed. I think that means that things work kind of as you want it to?

Comment 33

[Gabriele Svelto [:gsvelto]]

(In reply to Nathan Froyd [:froydnj] from comment #32)

Note that, for reasons, GPU (and I believe VR and RDD, who used GPU as a template) processes have the child and parent terminology reversed. I think that means that things work kind of as you want it to?

Yes they do, but now I want to cry.

When you say that the VR and RDD processes used the GPU one as a template do you mean it as "they had the same special requirements" or "they were cargo-culted that way"?

Comment 34

[Gabriele Svelto [:gsvelto]]

As usual I've been far too optimistic about the fix. I tried turning on the CrashReporterHost early and initializing it later - where we used to create it - and then artificially caused early crashes in content processes... and all hell broke loose. Enabling crash reporting so early in child process startup means that the crashes are notified and this leads other parts of the code to look for processes it doesn't know about yet. In other words, it's racy. Yet another reason to rewrite all of this stuff so that it lives in an out-of-process daemon, but I digress.

I believe I can make a simpler fix by letting the IPC parent objects "ignore" the minidump by completing it with a minimal .extra file. If this works it will make the crashes submittable but will not inform the user about them right away.

Comment 35

[Bogdan Maris, Desktop Test Engineering]

If this gets fixed in 68.0.2 can you please tell me if the fix could be verified by manual QA? If so can you provide some steps in order to reproduce and verify the fix?

Comment 36

[Gabriele Svelto [:gsvelto]]

Sure. I will attach a patch that makes it easy to reproduce the issue and I'll add instructions on verifying it manually.

Comment 37

[Gabriele Svelto [:gsvelto]]

I've got a fix for the minidump generation part which I'll put under bug 1282776 because it fixes that specific problem and I'm writing another one here to clean up .dmp files w/o .extra files attached.

Comment 38

[Gabriele Svelto [:gsvelto]]

Once the patch for bug 1282776 lands all crashes will have their .extra files again. The remaining question here is: how do we address crashes missing their .extra file in the about:crashes UI?

One idea I had is to display those crashes differently. I've hacked up a prototype where the incomplete crashes are listed in red and the "Submit" button is disabled. I'll attach a picture shortly to get UX feedback.

Comment 39

[Gabriele Svelto [:gsvelto]]

Attachment: UI prototype

Here's a snapshot of my prototype in action. Mike who should I ask for feedback on UI changes in the front-end?

Comment 40

[Gabriele Svelto [:gsvelto]]

The fix for bug 1282776 just landed and with it the root cause for this should be fixed. The fix to about:crashes I proposed in comment 39 is almost ready tests included. If the UI is OK we should be able to close this by the end of the week.

Comment 41

[Mike Conley (:mconley) (:⚙️)]

(In reply to Gabriele Svelto [:gsvelto] from comment #39)

Here's a snapshot of my prototype in action. Mike who should I ask for feedback on UI changes in the front-end?

I think historically, we've run these kinds of changes by shorlander, but I know he's pretty busy these days.

I think I might be able to predict something he'd say though - which is: why do we want to list these items if they're not things the user can do anything with? If we know that they're incomplete, we might just want to hide them (and eventually clear them out ourselves).

Comment 42

[Gabriele Svelto [:gsvelto]]

(In reply to Mike Conley (:mconley) (:⚙️) (Catching up from PTO) from comment #41)

I think I might be able to predict something he'd say though - which is: why do we want to list these items if they're not things the user can do anything with? If we know that they're incomplete, we might just want to hide them (and eventually clear them out ourselves).

My idea was that a (power) user could report them in Bugzilla like it happened in this bug. If we clear them up ourselves and never show them I would never have found the underlying issue.

Comment 43

[Mike Conley (:mconley) (:⚙️)]

(In reply to Gabriele Svelto [:gsvelto] from comment #42)

My idea was that a (power) user could report them in Bugzilla like it happened in this bug. If we clear them up ourselves and never show them I would never have found the underlying issue.

I see. In the event that there's an "Incomplete" entry in the list, beyond the fact that there's something in the list, is it likely that the user can provide more information that would be useful to help diagnose this kind of problem? It just looks completely unactionable as it is, except for clearing the list.

I wonder if we can somehow capture the same kind of information using Telemetry instead?

Comment 44

[Gabriele Svelto [:gsvelto]]

(In reply to Mike Conley (:mconley) (:⚙️) (Catching up from PTO) from comment #43)

I see. In the event that there's an "Incomplete" entry in the list, beyond the fact that there's something in the list, is it likely that the user can provide more information that would be useful to help diagnose this kind of problem? It just looks completely unactionable as it is, except for clearing the list.

We might ask the user to send us the minidump for manual inspection. That's the best we can do with the current tools.

I wonder if we can somehow capture the same kind of information using Telemetry instead?

We can certainly capture the presence of those crashes in telemetry.

Comment 45

[Mike Conley (:mconley) (:⚙️)]

(In reply to Gabriele Svelto [:gsvelto] from comment #44)

We might ask the user to send us the minidump for manual inspection. That's the best we can do with the current tools.

Alright, fair. In that case, my last piece of feedback would be to change the disabled "Incomplete" button to something else that makes it easier for the user to share the file with us - perhaps a "Open Folder" button instead, to take the user to where the file is stored. I think what I'm mostly rebelling against (and sorry for giving you such a hard time about it!) is presenting this information to the user without giving them anything they can readily do about it.

Comment 46

[Gabriele Svelto [:gsvelto]]

(In reply to Mike Conley (:mconley) (:⚙️) (Catching up from PTO) from comment #45)

Alright, fair. In that case, my last piece of feedback would be to change the disabled "Incomplete" button to something else that makes it easier for the user to share the file with us - perhaps a "Open Folder" button instead, to take the user to where the file is stored. I think what I'm mostly rebelling against (and sorry for giving you such a hard time about it!) is presenting this information to the user without giving them anything they can readily do about it.

I see your point and I've been pondering about this. "Open containing folder" would be better than nothing. An alternative would be to synthesize an "artificial" .extra file for them and let the user submit them anyway. With an adequate annotation those could be flagged as "incomplete" so that we know what we're dealing with.

Will WDYT? Would there be an easy way to flag a crash on Socorro as being incomplete given that the submission will contain an annotation saying so (e.g. MissingExtraFile=1 or something along the lines)?

Comment 47

[Will Kahn-Greene [:willkg] ET needinfo? me]

If a crash report gets sent with no annotations, then it'll get rejected--Socorro won't save or process it at all. Socorro requires that the crash report is from a supported product so it minimally checks the ProductName annotation.

If we synthesize an "artificial" .extra file with at least the ProductName (we probably want version, build id, and release channel, too), then we can add the indicator to the search fields (e.g. MissingExtraFile) so that they're searchable (easy change). I think that'll work fine.

Comment 48

[Gabriele Svelto [:gsvelto]]

(In reply to Will Kahn-Greene [:willkg] ET needinfo? me from comment #47)

If we synthesize an "artificial" .extra file with at least the ProductName (we probably want version, build id, and release channel, too), then we can add the indicator to the search fields (e.g. MissingExtraFile) so that they're searchable (easy change). I think that'll work fine.

Yeah, that's what I was thinking about. Just adding product name/version/build id/release channel plus an annotation that says the .extra file was missing and then sending it. I'll cook up a patch.

Comment 49

[Gabriele Svelto [:gsvelto]]

Attachment: Bug 1566855 - Submit incomplete crashes by synthesizing a minimal .extra file with sensible crash annotations

Comment 50

[Pulsebot]

Pushed by [e-mail]:
https://hg.mozilla.org/integration/autoland/rev/63633f034e0f
Submit incomplete crashes by synthesizing a minimal .extra file with sensible crash annotations r=mconley

Comment 51

[Ryan VanderMeulen [:RyanVM]]

This is a nice to have, but per IRC discussion with gsvelto, not necessary for uplift either. Bug 1282776 fixes the main issue which drove this in the first place.

Comment 52

[Alexandru Michis [:malexandru]]

https://hg.mozilla.org/mozilla-central/rev/63633f034e0f