Intermittent crash in speex_resampler_process_float

RESOLVED WORKSFORME

Status

()

defect
RESOLVED WORKSFORME
6 years ago
2 years ago

People

(Reporter: Ehsan, Unassigned)

Tracking

({crash, intermittent-failure})

Trunk
x86
Windows XP
Points:
---
Dependency tree / graph

Firefox Tracking Flags

(Not tracked)

Details

(crash signature)

Crash Signature: [@ speex_resampler_process_float]
Hardware: x86 → x86_64
Ted, is it possible to get minidumps from crashes that happen while running tests on our infrastructure?
Flags: needinfo?(ted)
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
Flags: needinfo?(ted)
Blocks: 876252
Depends on: 867104, 875144
Thanks Ted!  John, can you please help me with this?
Flags: needinfo?(jhopkins)
No longer blocks: 876252
Posted file minidump
(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
Flags: needinfo?(jhopkins)
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.
Depends on: 877865
(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.
Component: Video/Audio → Web Audio
It looks like Ehsan is investigating this, so I'll assign it to him.
Assignee: nobody → ehsan
(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.
Assignee: ehsan → nobody
Dear sheriffs: is this bug still happening?  We have fixed a large number of security bugs which might have been dupes of this one...
Flags: needinfo?(ryanvm)
Flags: needinfo?(emorley)
Hard to tell given comment 11...
Flags: needinfo?(ryanvm)
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
Flags: needinfo?(emorley)
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.
Status: NEW → RESOLVED
Closed: 6 years ago
Resolution: --- → WORKSFORME
Group: core-security → core-security-release
Group: core-security-release
You need to log in before you can comment on or make changes to this bug.