https://tbpl.mozilla.org/php/getParsedLog.php?id=23339552&tree=Mozilla-Inbound#error0 https://tbpl.mozilla.org/php/getParsedLog.php?id=23318078&tree=Mozilla-Inbound#error0 This is probably a security bug, continuation of bug 874915.

Ted, is it possible to get minidumps from crashes that happen while running tests on our infrastructure?

https://tbpl.mozilla.org/php/getParsedLog.php?id=23381179&tree=Fx-Team https://tbpl.mozilla.org/php/getParsedLog.php?id=23370814&tree=Fx-Team

Yes, if you can find a recent instance of it, you can ask someone in RelEng to connec to that slave and grab the minidump. For example: (In reply to Phil Ringnalda (:philor) from comment #4) > https://tbpl.mozilla.org/php/getParsedLog.php?id=23370814&tree=Fx-Team 12:00:47 INFO - mozcrash INFO | Saved dump as C:\talos-slave\test\build/../minidumps\9bbf09ba-c131-439a-a8f8-24c04be5c640.dmp

Thanks Ted! John, can you please help me with this?

(In reply to Phil Ringnalda (:philor) from comment #7) > https://tbpl.mozilla.org/php/getParsedLog.php?id=23460882&tree=Mozilla- > Central There was no c:\talos-slave\test\build/../minidumps\4f2f3df0-f7e3-47d3-aa47-b3b246143963.dmp on this slave, but here's the file which was at C:\talos-slave\test\minidumps

OK, I didn't have much chance using the minidump since the symbols are not uploaded to the try server and getting a stack is not possible, but let's see if I have a better chance on the try server: https://tbpl.mozilla.org/?tree=Try&rev=cd1ea2deaee1

So, the issue doesn't seem to happen on try at all! Am I missing something?

Yes, you're missing the fact that it happened seven times on slaves with names like talos-r3-xp-nnn, and with the exception of one run which you didn't see because it was hidden, all your runs were on slaves with names like t-xp32-ix-nnn. We replaced the old WinXP-on-ancient-Mac-mini slaves with shiny new hardware this morning, so you can only run tests on the old ones now by getting releng to loan you one fairly quickly, before they all get reimaged to a different OS.

(In reply to Phil Ringnalda (:philor) from comment #11) > Yes, you're missing the fact that it happened seven times on slaves with > names like talos-r3-xp-nnn, and with the exception of one run which you > didn't see because it was hidden, all your runs were on slaves with names > like t-xp32-ix-nnn. We replaced the old WinXP-on-ancient-Mac-mini slaves > with shiny new hardware this morning, so you can only run tests on the old > ones now by getting releng to loan you one fairly quickly, before they all > get reimaged to a different OS. Oh you're right! Silly me... I filed bug 877865 to get one of those ancient slaves. Hopefully I can install a debugger on it to debug the crash when it happens...

Mass moving Web Audio bugs to the Web Audio component. Filter on duckityduck.

It looks like Ehsan is investigating this, so I'll assign it to him.

(In reply to Andrew McCreight [:mccr8] from comment #14) > It looks like Ehsan is investigating this, so I'll assign it to him. Nope, not until somebody fixes bug 877865.

Dear sheriffs: is this bug still happening? We have fixed a large number of security bugs which might have been dupes of this one...

Hard to tell given comment 11...

We still use talos-r3-xp on mozilla-beta and mozilla-b2g18 (at least). Perhaps you could order up some extra runs on those trees, assuming the security fixes have not all been uplifted.

Dutto comment 17

Ditto, even

(In reply to Nick Thomas [:nthomas] from comment #18) > We still use talos-r3-xp on mozilla-beta and mozilla-b2g18 (at least). > Perhaps you could order up some extra runs on those trees, assuming the > security fixes have not all been uplifted. Hmm, problem is that the code in question has not been uplifted to beta...

I'm not sure exactly what our code supports, but would it help if we configured the profiling or some other project branch to run talos-r3-xp as well as, or instead of, the new hardware ? Or add talos-r3-xp back to try as non-default ?

(In reply to Nick Thomas [:nthomas] from comment #22) > I'm not sure exactly what our code supports, but would it help if we > configured the profiling or some other project branch to run talos-r3-xp as > well as, or instead of, the new hardware ? Or add talos-r3-xp back to try as > non-default ? Let me see if I can get anywhere with my investigations on this slave that I have. Otherwise, I guess running profiling on talos-r3-xp would probably make sense.

I'm currently running these tests 1000 times on the slave to see if I can reproduce.

OK, I ran this test 2000 times, and did not get a crash. I'm going to say that this is fixed now.