I thought this would be a Windows-only issue, but it seems that macOS is potentially a bit more affected, while Linux seems mostly immune. Here is an experiment: choose a `build id`, and get the `debug_id` for `xul` for this build. Then list all crashes that have `xul` with this `debug_id` in `modules in stack`, and aggregate over `build id`. Sometimes, you will find that there are crash reports where the build id is not the expected one. This gives less precise results than the methodology from comment 13 but it can be used on crash-stats directly, and can thus give an estimate of the dates where we should find the most mismatched crashes for a given `build id` if we apply the methodology from comment 13. Some examples: - `xul/d591692ab6c83b95a0d75fc1d1e0594e0` from 119.0 macOS x64 release appears in the stack of 49 crashes that have older build ids than `20231019122658`, the majority (17) of those mismatched crashes were reported on 2023-10-27; - `xul/ac616d5c25ca382d9ce25b04105a22d40` from 119.0 macOS arm64 release appears in the stack of 49 crashes that have older build ids than `20231019122658`, the majority (9) of those mismatched crashes were reported on 2023-10-25; - `xul.dll/1bc43681d14caaa74c4c44205044422e1` from 118.0.2 Windows x64 release appears in the stack of 19 crashes that have older build ids than `20231019122658`, the majority (4) of those mismatched crashes were reported on 2023-10-17; - `xul.dll/569e0a6c6b88c1564c4c44205044422e1` from 115.4.0esr Windows x86 release appears in the stack of 25 crashes that have older build ids than `20231016232700`, the majority (5) of those mismatched crashes were reported on 2023-10-25. In summary, these mismatched crashes seem to coincide with update release dates, then they tend to disappear after that. They do not seem to represent a very significant part of our crash volume. It would be good to confirm that by applying the methodology of comment 13 to the examples given above. Also, here we are focusing on `xul`. This makes sense because that would be the biggest source of poorly bucketed crashes. However there could be crashes where there are mismatches in other modules but not in `xul`.
Bug 1861359 Comment 14 Edit History
Note: The actual edited comment in the bug view page will always show the original commenter’s name and original timestamp.
I thought this would be a Windows-only issue, but it seems that macOS is potentially a bit more affected, while Linux seems mostly immune. Here is an experiment: choose a `build id`, and get the `debug_id` for `xul` for this build. Then list all crashes that have `xul` with this `debug_id` in `modules in stack`, and aggregate over `build id`. Sometimes, you will find that there are crash reports where the build id is not the expected one. This gives less precise results than the methodology from comment 13 but it can be used on crash-stats directly, and can thus give an estimate of the dates where we should find the most mismatched crashes for a given `build id` (so we can later apply the methodology from comment 13). Some examples: - `xul/d591692ab6c83b95a0d75fc1d1e0594e0` from 119.0 macOS x64 release appears in the stack of 49 crashes that have older build ids than `20231019122658`, the majority (17) of those mismatched crashes were reported on 2023-10-27; - `xul/ac616d5c25ca382d9ce25b04105a22d40` from 119.0 macOS arm64 release appears in the stack of 49 crashes that have older build ids than `20231019122658`, the majority (9) of those mismatched crashes were reported on 2023-10-25; - `xul.dll/1bc43681d14caaa74c4c44205044422e1` from 118.0.2 Windows x64 release appears in the stack of 19 crashes that have older build ids than `20231019122658`, the majority (4) of those mismatched crashes were reported on 2023-10-17; - `xul.dll/569e0a6c6b88c1564c4c44205044422e1` from 115.4.0esr Windows x86 release appears in the stack of 25 crashes that have older build ids than `20231016232700`, the majority (5) of those mismatched crashes were reported on 2023-10-25. In summary, these mismatched crashes seem to coincide with update release dates, then they tend to disappear after that. They do not seem to represent a very significant part of our crash volume. It would be good to confirm that by applying the methodology of comment 13 to the examples given above. Also, here we are focusing on `xul`. This makes sense because that would be the biggest source of poorly bucketed crashes. However there could be crashes where there are mismatches in other modules but not in `xul`.
I thought this would be a Windows-only issue, but it seems that macOS is potentially a bit more affected, while Linux seems mostly immune. Here is an experiment: choose a `build id`, and get the `debug_id` for `xul` for this build. Then list all crashes that have `xul` with this `debug_id` in `modules in stack`, and aggregate over `build id`. Sometimes, you will find that there are crash reports where the build id is not the expected one. This gives less precise results than the methodology from comment 13 but it can be used on crash-stats directly, and can thus give an estimate of the dates where we should find the most mismatched crashes for a given `build id` (so we can later apply the methodology from comment 13). Some examples: - `xul/d591692ab6c83b95a0d75fc1d1e0594e0` from 119.0 macOS x64 release appears in the stack of 49 crashes that have older build ids than `20231019122658`, the majority (17) of those mismatched crashes were reported on 2023-10-27; - `xul/ac616d5c25ca382d9ce25b04105a22d40` from 119.0 macOS arm64 release appears in the stack of 49 crashes that have older build ids than `20231019122658`, the majority (9) of those mismatched crashes were reported on 2023-10-25; - `xul.dll/1bc43681d14caaa74c4c44205044422e1` from 118.0.2 Windows x64 release appears in the stack of 19 crashes that have older build ids than `20231019122658`, the majority (4) of those mismatched crashes were reported on 2023-10-17; - `xul.dll/569e0a6c6b88c1564c4c44205044422e1` from 115.4.0esr Windows x86 release appears in the stack of 25 crashes that have older build ids than `20231016232700`, the majority (5) of those mismatched crashes were reported on 2023-10-25. In summary, these mismatched crashes seem to coincide with update release dates, then they tend to disappear after that. They do not seem to represent a very significant part of our crash volume. It would be good to confirm that, by applying the methodology of comment 13 to the examples given above. Also, here we are focusing on `xul`. This makes sense because that would be the biggest source of poorly bucketed crashes. However there could be crashes where there are mismatches in other modules but not in `xul`.