When starting up, UpdateCrashEventsDir() gets called twice - immediately[1], and when we have a profile[2]. In both instances the calls to NS_GetSpecialDirectory() for "ProfD" and "UAppData" fail. It's not until OOPInit() runs that UpdateCrashEventsDir() will actually set a directory [3]. This has the result that events may not be recorded for crashes that happen early, or at all if browser.tabs.remote is false. [1] http://mxr.mozilla.org/mozilla-central/source/toolkit/xre/nsAppRunner.cpp?rev=1d166a3a207d#3024 [2] http://mxr.mozilla.org/mozilla-central/source/toolkit/xre/nsAppRunner.cpp?rev=1d166a3a207d#3679 [3]http://mxr.mozilla.org/mozilla-central/source/toolkit/crashreporter/nsExceptionHandler.cpp?rev=62f2593a6412#2556

Adding to backlog due to blocking bug 994707.

Sounds like this is basically the same as bug 820716?

Comment on attachment 8417729 [details] [diff] [review] 1004623-UpdateCrashEventsDir Review of attachment 8417729 [details] [diff] [review]: ----------------------------------------------------------------- ::: toolkit/crashreporter/nsExceptionHandler.cpp @@ +2142,5 @@ > + } > + > + rv = NS_GetSpecialDirectory("UAppData", getter_AddRefs(eventsDir)); > + if (NS_SUCCEEDED(rv)) { > + SetProfileDirectory(eventsDir); Uh, do you have these two calls reversed? It looks like you're calling SetProfileDirectory where you mean to call SetUserAppDataDirectory and vice versa.

Yes I did (the impls were reversed also)! Good catch. I had to add an env check to the generic method in order to fix xpcshell tests. https://hg.mozilla.org/integration/fx-team/rev/0202366e8b70

This really should be QA-verified. Here's my steps: * Launch Firefox. Make sure that no plugins including are used in the session * Crash Firefox using the instructions at https://developer.mozilla.org/en-US/docs/How_to_Report_a_Hung_Firefox * Go to about:healthreport -> Raw Data and look in data.days for the current day. Expected: * There should be a record "org.mozilla.crashes.crashes _v: 2 "mainCrash" <count, at least 1> Before today's nightly there won't be a record, because we never launched a plugin. After today's nightly there should be a record.

I verified this bug using the following environment: FF 32 Build Id: 20140508030203 OS : Win 8 x64, Ubuntu 12.10 x86, Mac Os x 10.8.5 On windows and linux some of the crashes are registered and others are not(the count is not increasing for each crash), even strangely some of the crashes are not registered at first but after another crash both of the crashes are registered. On Mac after 5 crashes not a single one was registered. In order to verify the bug I've used the steps provided by comment 7 . From this testing this bug doesn't seem completely fixed. If my expected behavior is not correct or I'm missing some information please provide feedback.

After a crash, it may take up to 90 seconds for a crash to register: we only look for crash files a minute after startup. So it sounds like the Linux/Windows thing might be fine. Interesting results about mac: I'll follow up on that. Did you see the crash reporter dialog come up when you sent the sigabrt on mac?

The crash reporter dialog came up when I've sent sigabrt on mac.

I verified that this works on mac nightlies as long as you wait for the delay: the FHR payload may also be delayed, but a restart fixes that.