SUMO community discussions

issues with fetching crash reports

  1. lately i seem to have troubles loading new crash reports, for example here and here - they will just time out after a few minutes ("Oh Noes! This archived report could not be located.")
    can others confirm that it's happening universally or is it just me...?

    lately i seem to have troubles loading new crash reports, for example [https://support.mozilla.org/en-US/questions/971150#answer-483497 here] and [https://support.mozilla.org/en-US/questions/972334#answer-483536 here] - they will just time out after a few minutes ("Oh Noes! This archived report could not be located.") <br>can others confirm that it's happening universally or is it just me...?
  2. I would be interested in the answers.

    • Crash bp-0e7b391a-aa4b-4dbf-b189-91fa52130919 /questions/972334
      I wonder if part of the problem is the type of Crash Report we are looking at.
    • /questions/971150#answer-483497
      I wonder if it could be the crash reports again. The Crash ID reports are interspersed with a lot that are not submitted.
    I would be interested in the answers. * ''Crash bp-0e7b391a-aa4b-4dbf-b189-91fa52130919'' [/questions/972334]<br />I wonder if part of the problem is the type of Crash Report we are looking at. * [/questions/971150#answer-483497] <br /> I wonder if it could be the crash reports again. The Crash ID reports are interspersed with a lot that are not submitted.
  3. I've noticed this as well in a few cases and also wondered if something is wrong.

    I've noticed this as well in a few cases and also wondered if something is wrong. *[[/questions/972334]]
  4. I can reproduce. Not sure what's up

    I can reproduce. Not sure what's up
  5. more options

    I have "issues with fetching crash reports" quite frequently as of late.

    Overall, trying to retrieve Crash Reports that are brand new (same day as the crash happened) and sometimes crashes that happened within the last 72 hours after the crash report was sent, can cause the page to take up to 5 tries to find and display the crash data. After the 5th try, the system stops looking and shows that "Oh Noes!" message. I have been seeing this happen on and off for quite a long time now, but recently it's become epidemic.

    Currently, I avoid doing crash report support all too often when my level of patience is low. Sometimes I end up waiting waiting up to two and a half minutes just to see 5 or more empty crash reports .....


    I am wondering how the crash reporting system is set up. My perception based upon my observation is that there are multiple servers receiving the crash data, possibly at multiple locations around the globe.

    And then there is a "master server" or server cluster at crash-stats.mozilla.com, that is what we use to access the crash reports and to read them. We enter the Crash ID# (or use hyperlink the user provides) and that "master server" searches the "receiving servers" for the Crash ID and once that report is found, it downloads the report to the "master server" for viewing, which then retains that data for period of time allowing other people to view that report without that report needing to be searched for again.


    In the past, before "common responses" was instituted, my "clipping" included asking the Owner of the thread to load each crash report. I could tell which users did that and which users didn't "pre-retrieve" their reports.

    Sometimes I would open 5 reports in tabs, and by the time I opened the first tab the report was already completely loaded. When the user couldn't be bothered to do that small thing to aid with the support process, I would find myself waiting for the reports to be located and displayed.

    IMO, "we" need to either have the forum software "pre-retrieve" posted ID's automatically as soon as the Reply is posted by the user or add a request to the "crashes" responses for the user to load each crash report them self to "pre-retrieve" their cash reports.


    I know the volume of crash reports can be immense, and lately so immense that the system won't accept all crash reports that are generated (I seen a pattern of not accepted increase of the last few years in my own Firefox installation, and lately just over half appear to have not been submitted). I realize Mozilla is working hard to reduce the incidence of Firefox crashing and thus the number reports submitted, but SUMO needs to something to speed up the retrieval process for the purpose of support. Or pay support personnel to do crash support, and "do the sitting" while crash-stats.mozilla.com looks for the users crash reports. Personally, I am almost to the point of just not opening any postings tagged with "crash" - too damn many problems with Flash caused crashes since Flash 11 came out (I'm still using 10.3 for this exact reason), too many empty crash reports, and the time it takes to retrieve / view the crash reports.

    The last one has become a "deal-killer" for me continuing to do crash support!

    I have "issues with fetching crash reports" quite frequently as of late. Overall, trying to retrieve Crash Reports that are brand new ''(same day as the crash happened)'' and sometimes crashes that happened within the last 72 hours after the crash report was sent, can cause the page to take up to 5 tries to find and display the crash data. After the 5th try, the system stops looking and shows that "Oh Noes!" message. I have been seeing this happen on and off for quite a long time now, but recently it's become epidemic. Currently, I avoid doing crash report support all too often when my level of patience is low. Sometimes I end up waiting waiting up to two and a half minutes just to see 5 or more empty crash reports ..... ------- I am wondering how the crash reporting system is set up. My perception based upon my observation is that there are multiple servers receiving the crash data, possibly at multiple locations around the globe. And then there is a "master server" or server cluster at crash-stats.mozilla.com, that is what we use to access the crash reports and to read them. We enter the Crash ID# (or use hyperlink the user provides) and that "master server" searches the "receiving servers" for the Crash ID and once that report is found, it downloads the report to the "master server" for viewing, which then retains that data for period of time allowing other people to view that report without that report needing to be searched for again. ------ In the past, before "common responses" was instituted, my "clipping" included asking the Owner of the thread to load each crash report. I could tell which users did that and which users didn't "pre-retrieve" their reports. Sometimes I would open 5 reports in tabs, and by the time I opened the first tab the report was already completely loaded. When the user couldn't be bothered to do that small thing to aid with the support process, I would find myself waiting for the reports to be located and displayed. IMO, "we" need to either have the forum software "pre-retrieve" posted ID's automatically as soon as the Reply is posted by the user or add a request to the "crashes" responses for the user to load each crash report them self to "pre-retrieve" their cash reports. ----- I know the volume of crash reports can be immense, and lately so immense that the system won't accept all crash reports that are generated ''(I seen a pattern of not accepted increase of the last few years in my own Firefox installation, and lately just over half appear to have not been submitted)''. I realize Mozilla is working hard to reduce the incidence of Firefox crashing and thus the number reports submitted, but SUMO needs to something to speed up the retrieval process for the purpose of support. '''Or''' pay support personnel to do crash support, and "do the sitting" while crash-stats.mozilla.com looks for the users crash reports. Personally, I am almost to the point of just not opening any postings tagged with "crash" - too damn many problems with Flash caused crashes since Flash 11 came out ''(I'm still using 10.3 for this exact reason)'', too many empty crash reports, and the time it takes to retrieve / view the crash reports. The last one has become a "deal-killer" for me continuing to do crash support!
  6. i wouldn't mind waiting a bit until they are loaded, if they would just load at all (i normally just open all linked reports in background tabs when i get to a crash related question and go through the question details in the meantime)...

    i wouldn't mind waiting a bit until they are loaded, if they would just load at all (i normally just open all linked reports in background tabs when i get to a crash related question and go through the question details in the meantime)...
  7. i've filed bug 921443 for it...

    i've filed [https://bugzilla.mozilla.org/show_bug.cgi?id=921443 bug 921443] for it...
  8. Hey, I've identified the issue and I'm working on a fix. I will update bug 921443 as the work is completed.

    Hey, I've identified the issue and I'm working on a fix. I will update [https://bugzilla.mozilla.org/show_bug.cgi?id=921443 bug 921443] as the work is completed.
  9. more options

    Damn, fast service. Within 20 minutes of filing that Bug report :brandon responded and 8 minutes later he grabbed that Bug to fix.

    Damn, fast service. Within 20 minutes of filing that Bug report :brandon responded and 8 minutes later he grabbed that Bug to fix.
  10. I do not really follow such topics but I guess it is related to this * http://www.twobraids.com/2013/09/the-socorro-monitor-rest-in-peace.html *http://www.brandonsavage.net/socorro-releases-rabbitmq-into-production
  11. more options

    Well - http://www.brandonsavage.net/socorro-releases-rabbitmq-into-production - validates a number of my observations about how the system works.

    Well - http://www.brandonsavage.net/socorro-releases-rabbitmq-into-production - validates a number of my observations about how the system works.
  12. Thanks Brandon,

    That was quick,it looks as if it is already fixed. At least I can see someof those crash reports now.

    Thanks Brandon, That was quick,it looks as if it is already fixed. At least I can see someof those crash reports now.
  13. We manually processed some of the backlogged jobs. I've pushed up a patch for the issue and we should release an updated Socorro today, so it should be fixed here soon. I'll update once it's fixed for good.

    We manually processed some of the backlogged jobs. I've pushed up a patch for the issue and we should release an updated Socorro today, so it should be fixed here soon. I'll update once it's fixed for good.
  14. This feature has been fixed in the newly released Socorro 61. Please file a new bug if you have any further issues!

    This feature has been fixed in the newly released Socorro 61. Please file a new bug if you have any further issues!