1. go to https://crash-stats.mozilla.com/topcrasher/byversion/FennecAndroid/14.0b3/7 2. look at mozilla::hal::NotifyScreenOrientationChange (should be #19) and the associated bugs Expected: bugs associated are listed Actual: bugs associated are not listed Note: if you click on the link then go to the bug tab you will see the associated bug numbers
Dupe of bug 759341?
(In reply to Scoobidiver from comment #1) > Dupe of bug 759341? How should it be? There's no / in the signature, and this is about bug numbers showing in the topcrashers list, not about being able to view a page. Interestingly, in an advanced query, we correctly show those bug numbers.
(In reply to Robert Kaiser (:email@example.com) from comment #2) > (In reply to Scoobidiver from comment #1) > > Dupe of bug 759341? > How should it be? There's no / in the signature, and this is about bug > numbers showing in the topcrashers list, not about being able to view a page. The first crash signature containing / is #18 top crasher, so almost all crashes after it including bug 740329 don't have a related bug because the cronjob failed.
(In reply to Scoobidiver from comment #3) > The first crash signature containing / is #18 top crasher, so almost all > crashes after it including bug 740329 don't have a related bug because the > cronjob failed. It's not the cronjob that failed, but you might be right in an XHR or mware request being what failed there.
Right now, as I check this, bugs 757025, 740329 are listed in the bugzilla tab for that signature, and shown on topcrasher row for it. KaiRo pointed out that there are others on that page (libflashplayer.so@0x50ccd4, currently 36 and nsNPAPIPluginInstance::TimerWithID, currently 37) with the descibed problem.
Kicking out to 14. This is difficult to reproduce locally or on crash-stats-dev, as neither have Bugzilla information. So far I can only reproduce it on FennecAndroid. All examples I have found involve signatures with a double colon ("::") substring.
Target Milestone: 13 → 14
The TCBS query to the middleware triggers a SQL search with 23 signatures, instead of the expected 300. After some investigation, it looks like 40+ signatures are arriving with the post data, but only 23 are being returned by the external_common.parse_arguments() function.
This is being caused by a slash in the POST data, specifically the signature: `java.util.concurrent.RejectedExecutionException: pool=1/1, queue=0 at java.util.`
(In reply to Chris Lonnen :lonnen from comment #8) > This is being caused by a slash in the POST data I though bug 759341 was supposed to fix that.
(In reply to Scoobidiver from comment #9) > (In reply to Chris Lonnen :lonnen from comment #8) > > This is being caused by a slash in the POST data > I though bug 759341 was supposed to fix that. No, those are totally different problems: bug 759341 was due to Apache not accepting encoded slashes in URLs. Here the problem is caused by an internal function splitting a string on slashes, and we introduced non-encoded and unexpected slashes in that string.
Won't get to this before today's freeze. Kicking to 15.
Target Milestone: 14 → 15
bug fixed, but tests are broken. will land for next week.
Target Milestone: 15 → 16
My last patch was not viable. Some of the code paths it modified are reused in too many places to do this without adding complexity. Needs a new approach.
Target Milestone: 16 → 17
Created attachment 643586 [details] fixed on c-s-d This was fixed by adrian's solution for bug 774777. To verify, find a signature with a slash that has a bug associated with it. I've attached a screen cap from staging where I found one on FennecAndroid 14.
Status: NEW → RESOLVED
Last Resolved: 7 years ago
Resolution: --- → FIXED
You need to log in before you can comment on or make changes to this bug.