SUMO community discussions

Crash fixing process in Beta builds

  • 7 replies
  • Last reply by scoobidiver
  1. scoobidiver
    scoobidiver 1275 posts
    more options

    John99 said

    Could something like Google Toolbar eventually cause a large number of crashes that would not be noticed, other than if anyone monitored fluctuations in the number of no signature crash reports. (maybe someone does ? & maybe somehow action is being taken to reduce numbers of such reports?)

    Crash signatures are monitored by the crash kill team and if a new top crash signature appears in the first Beta builds, the bug is tracked and, if possible, a patch is released in one of the next builds (e.g. bug 618683), except if the patch has an impact on add-on compatibilities. In this case, it lands only in Aurora builds to let add-on developers time to fix their add-on.

    The specific empty signature is a breakdown of all possible crash signatures, so if an add-on had an influence on a crash signature, it would be seen in the related crash signature.

    ''John99 [/forums/knowledge-base-articles/707162#post-41286 said]'' <blockquote> Could something like Google Toolbar eventually cause a large number of crashes that would not be noticed, other than if anyone monitored fluctuations in the number of no signature crash reports. (maybe someone does ? & maybe somehow action is being taken to reduce numbers of such reports?) </blockquote> Crash signatures are monitored by the crash kill team and if a new top crash signature appears in the first Beta builds, the bug is tracked and, if possible, a patch is released in one of the next builds (e.g. [https://bugzilla.mozilla.org/show_bug.cgi?id=618683 bug 618683]), except if the patch has an impact on add-on compatibilities. In this case, it lands only in Aurora builds to let add-on developers time to fix their add-on. The specific empty signature is a breakdown of all possible crash signatures, so if an add-on had an influence on a crash signature, it would be seen in the related crash signature.
  2. John99
    John99 3665 posts
    more options

    This may not be on topic for this thread but does relate to my comment that is in the op above. Crashes with No signature are currently the top crash or one of the top three crashes in Firefox.

    My comment related to the fact that the no signature crash reports are very common

    • but do not convey any useful information to the user who has had the crash or to any one else looking at that category
    • presumably they will cover a multitude of reasons for crashes, any cause that is lumped into this category is not going to receive attention
    • the no signature crash reports are often high in the to crashes list Looking at the top crashers null signature crashes are top of close to the top in the list

    Whereas many of the top crashes will have associated bugs listed the empty crash signature crashes do not. I have not really found any links fully explaining the reason for this, apparently it is some inherent failure in the crash reporter not being always being able to pick up crash signatures (as explained here). I do not see any bug relating to fixing the cause of the no signature in the tracker. (Maybe any such the bugs are on the Google site somewhere ?)

    scoobidiver said

    The specific empty signature is a breakdown of all possible crash signatures, so if an add-on had an influence on a crash signature, it would be seen in the related crash signature.

    You clearly understand the crashes better than I do, and can probably provide suitable links to further info. I am do not follow the reasoning that The specific empty signature is a breakdown of all possible crash signatures, I am under the impression that the no signature crashes are as it says i.e. crashes with empty signatures, where the user and the tracker do not see any signature from the original crash, because no crash signature is identified from the specific crash ID.

    It appears to me that this is not a breakdown, as in an analysis;
    it is a breakdown as in a failure to analyse.

    This may not be on topic for this thread but does relate to my comment that is in the op above. Crashes with ''No signature'' are currently the top crash or one of the top three crashes in Firefox. My comment related to the fact that the '''''no signature''''' crash reports are very common * but do not convey any useful information to the user who has had the crash or to any one else looking at that category * presumably they will cover a multitude of reasons for crashes, any cause that is lumped into this category is not going to receive attention * the no signature crash reports are often high in the to crashes list Looking at the [https://crash-stats.mozilla.com/products/Firefox top crashers] null signature crashes are top of close to the top in the list ** Fx 8 #3 , @ 3.45% ** Fx 7 the #1 , top crasher @ 6.06% is empty signature crashes ** '''Fx 6 again the #1 , top crasher @ 6.96% {Beta channel] ''' <br/> https://crash-stats.mozilla.com/topcrasher/byversion/Firefox/7.0a2/7# ** Fx 5 #2 , @ 1.98% Whereas many of the top crashes will have associated bugs listed the empty crash signature crashes do not. I have not really found any links fully explaining the reason for this, apparently it is some inherent failure in the crash reporter not being always being able to pick up crash signatures [http://code.google.com/p/socorro/wiki/NullOrEmptySignatures (as explained here)]. I do not see any bug relating to fixing the cause of the no signature in the tracker. (Maybe any such the bugs are on the Google site somewhere ?) ''scoobidiver [[#post-41289|said]]'' <blockquote> The specific empty signature is a breakdown of all possible crash signatures, so if an add-on had an influence on a crash signature, it would be seen in the related crash signature. </blockquote> You clearly understand the crashes better than I do, and can probably provide suitable links to further info. I am do not follow the reasoning that ''The specific empty signature is a '''''breakdown''''' of all possible crash signatures, '' I am under the impression that the no signature crashes are as it says i.e. crashes with empty signatures, where the user and the tracker do not see any signature from the original crash, because no crash signature is identified from the specific crash ID. It appears to me that this is not a breakdown, as in an analysis; <br/>it is a breakdown as in a failure to analyse.
  3. scoobidiver
    scoobidiver 1275 posts
    more options

    John99 said

    I am do not follow the reasoning that The specific empty signature is a breakdown of all possible crash signatures

    It means that, behind the reports with an empty or null crash signature, there are no unknown or mysterious crash signatures. If a report had been generated, it would have had a known crash signature. This signature only biases the crasher breakdown.

    ''John99 [[#post-41322|said]]'' <blockquote> I am do not follow the reasoning that ''The specific empty signature is a '''''breakdown''''' of all possible crash signatures'' </blockquote> It means that, behind the reports with an empty or null crash signature, there are no unknown or mysterious crash signatures. If a report had been generated, it would have had a known crash signature. This signature only biases the crasher breakdown.
  4. John99
    John99 3665 posts
    more options

    I am not sure I understand the meaning behind what you are saying.

    scoobidiver said

    It means that, behind the reports with an empty or null crash signature, there are no unknown or mysterious crash signatures. If a report had been generated, it would have had a known crash signature. This signature only biases the crasher breakdown.

    There ARE mysterious crashes that are recorded and have "no crash signature". There are so many crashes with no signature that they are in fact the number one top crash category for the Firefox Beta channel and the number two top crasher for the Release channel.

    Because these crashes have no crash signature bugs are not filed and users are unable to get help on them.

    I may understand the situation if the "no signature crashes" were lower in the ranking, outside the top ten or top twenty; but not when they are at the top of the ranking order.

    I am not sure I understand the meaning behind what you are saying. ''scoobidiver [[#post-41326|said]]'' <blockquote> It means that, behind the reports with an empty or null crash signature, there are no unknown or mysterious crash signatures. If a report had been generated, it would have had a known crash signature. This signature only biases the crasher breakdown. </blockquote> There ARE mysterious crashes that are recorded and have "no crash signature". There are so many crashes with ''no signature'' that they are in fact the number one top crash category for the Firefox Beta channel and the number two top crasher for the Release channel. Because these crashes have ''no crash signature'' bugs are not filed and users are unable to get help on them. I may understand the situation if the "no signature crashes" were lower in the ranking, outside the top ten or top twenty; but not when they are at the top of the ranking order.
  5. scoobidiver
    scoobidiver 1275 posts
    more options

    The null crash signature is caused by a corrupted crash dump, so it's probably an existing crash signature that can't be linked but not necessarily the same, that why I talked about breakdown.
    As you said, the empty crash signature may indeed hide several unknown crash signatures as the crashing thread can't be determined.
    In conclusion, if real crash signatures were determined, none of these would probably be a top crasher.
    For more about Breakpad, see http://code.google.com/p/google-breakpad/.

    The purpose of this discussion is to help troubleshoot users and, for that, there is currently Troubleshoot Firefox crashes (closing or quitting unexpectedly) and will be soon Refresh Firefox - reset add-ons and settings. You can eventually by-pass some sections of one of these articles if the bug associated to the crash signature gives some clues, but that's all.

    The '''null''' crash signature is caused by a corrupted crash dump, so it's probably an existing crash signature that can't be linked but not necessarily the same, that why I talked about breakdown.<br> As you said, the '''empty''' crash signature may indeed hide several unknown crash signatures as the crashing thread can't be determined.<br> In conclusion, if real crash signatures were determined, none of these would probably be a top crasher.<br> For more about Breakpad, see http://code.google.com/p/google-breakpad/. The purpose of this discussion is to help troubleshoot users and, for that, there is currently [[Firefox crashes]] and will be soon [[How do I fix Firefox?]]. You can eventually by-pass some sections of one of these articles if the bug associated to the crash signature gives some clues, but that's all.
  6. John99
    John99 3665 posts
    more options

    There are indisputably very many crashes where no crash signature is obtained, and I do not see why we should expect that any other crash instances having the same cause would give a signature on some occaisons but not on others; such crashes do not get any easy resolution.

    I personally have not discovered any information to confirm your assertion that such crashes are "probably an existing crash signature" I may be wrong but my opinion would be that they may well be crashes that are otherwise unknown, and the cause is likely to remain unknown because of the failure to obtain a crash signature. I see no evidence that anyone is investigating this category of crashes.

    One example thread I remember: /questions/825937 a new profile solved the problem, but the crashes were not getting a crash signature, the actual cause was not discovered. The problem in that thread did not relate to a one off failure in obtaining crash signatures, multiple attempts were made to obtain a crash signature.

    P.S.
    I do not think kb articles are offering users advice about what to do if they get a null crash signature, they are just left with no advice.

    There are indisputably very many crashes where no crash signature is obtained, and I do not see why we should expect that any other crash instances having the same cause would give a signature on some occaisons but not on others; such crashes do not get any easy resolution. I personally have not discovered any information to confirm your assertion that such crashes are '' "probably an existing crash signature" '' I may be wrong but my opinion would be that they may well be crashes that are otherwise unknown, and the cause is likely to remain unknown because of the failure to obtain a crash signature. I see no evidence that anyone is investigating this category of crashes. One example thread I remember: [/questions/825937] a new profile solved the problem, but the crashes were not getting a crash signature, the actual cause was not discovered. The problem in that thread did not relate to a one off failure in obtaining crash signatures, multiple attempts were made to obtain a crash signature. ------ P.S. <br/> I do not think kb articles are offering users advice about what to do if they get a null crash signature, they are just left with no advice.

    Modified by John99 on

  7. AliceWyman
    AliceWyman 6489 posts
    more options

    Just thought I'd mention that we are suggesting that people install the Add-on Compatibility Reporter in the Re-enable add-ons that were disabled when updating Firefox article, to enable the Google Toolbar and other extensions that are disabled due to incompatibility. The danger is that some of those enabled extensions are actually not compatible and can cause multiple problems, even crash Firefox at startup (ref: Bug 658780 - Start-up crash with incompatible version of some extensions ...). We do have a "Warning" in the Re-enable add-ons that were disabled when updating Firefox article (While using the Add-on Compatibility Reporter you may find that an incompatible add-on causes Firefox to crash. In that case, see Disable or remove Add-ons for instructions to remove it.) but maybe the Troubleshoot Firefox crashes (closing or quitting unexpectedly) or Troubleshoot extensions, themes and hardware acceleration issues to solve common Firefox problems articles should also include a warning about the Add-on Compatibility Reporter, if we are going to continue suggesting that people use that add-on to force compatibility.

    Just thought I'd mention that we are suggesting that people install the Add-on Compatibility Reporter in the [[Add-ons are disabled after updating Firefox]] article, to enable the Google Toolbar and other extensions that are disabled due to incompatibility. The danger is that some of those enabled extensions are actually not compatible and can cause multiple problems, even crash Firefox at startup (ref: [https://bugzilla.mozilla.org/show_bug.cgi?id=658780 Bug 658780 - Start-up crash with incompatible version of some extensions ...]). We do have a "Warning" in the [[Add-ons are disabled after updating Firefox]] article (''While using the Add-on Compatibility Reporter you may find that an incompatible add-on causes Firefox to crash. In that case, see [[Uninstalling add-ons]] for instructions to remove it.'') but maybe the [[Firefox crashes]] or [[Troubleshooting extensions and themes]] articles should also include a warning about the Add-on Compatibility Reporter, if we are going to continue suggesting that people use that add-on to force compatibility.

    Modified by AliceWyman on

  8. scoobidiver
    scoobidiver 1275 posts
    more options

    John99 said

    I see no evidence that anyone is investigating this category of crashes.

    It's impossible to investigate. The only way to do that is that null and empty crash signatures become valid crash signatures. See the Issues tab in the Google Breakpad project link above. Anyway, that's not a SUMO problem.

    I do not think kb articles are offering users advice about what to do if they get a null crash signature, they are just left with no advice.

    Michael wants users troubleshoot the same way whatever the cause. See this thread.

    ''John99 [[#post-41388|said]]'' <blockquote> I see no evidence that anyone is investigating this category of crashes. </blockquote> It's impossible to investigate. The only way to do that is that null and empty crash signatures become valid crash signatures. See the Issues tab in the Google Breakpad project link above. Anyway, that's not a SUMO problem. <blockquote> I do not think kb articles are offering users advice about what to do if they get a null crash signature, they are just left with no advice. </blockquote> Michael wants users troubleshoot the same way whatever the cause. See [/forums/knowledge-base-articles/707113 this thread].