Open Bug 1061675 Opened 5 years ago Updated Last year

Intermittent test_mozaudiochannel.html | Test timed out, | application timed out after 330 seconds with no output, | application ran for longer than allowed maximum time

Categories

(Core :: Web Audio, defect, P4)

ARM
Linux
defect

Tracking

()

Tracking Status
firefox37 --- disabled
firefox38 --- disabled

People

(Reporter: cbook, Unassigned)

References

()

Details

(Keywords: intermittent-failure, Whiteboard: [test disabled on Android 4.3])

Android 2.3 Emulator fx-team opt test mochitest-6 on 2014-09-02 05:23:44 PDT for push 99d6c547dccb

slave: tst-linux64-spot-625

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

182 INFO TEST-UNEXPECTED-FAIL | /tests/content/media/webaudio/test/test_mozaudiochannel.html | Test timed out.
(In reply to TBPL Robot from comment #24)
> submit_timestamp: 2014-10-08T12:30:35
> log:
> https://treeherder.mozilla.org/ui/logviewer.html#?repo=fx-team&job_id=850698
> repository: fx-team
> who: rvandermeulen[at]mozilla[dot]com
> machine: tst-linux64-spot-581
> buildname: Android 2.3 Emulator fx-team opt test mochitest-6
> revision: 50565aa74892
> 
> TEST-UNEXPECTED-FAIL |
> /tests/content/media/webaudio/test/test_mozaudiochannel.html | application
> timed out after 330 seconds with no output
> PROCESS-CRASH | /tests/content/media/webaudio/test/test_mozaudiochannel.html
> | application crashed [@ libc.so + 0xc51c]

The crash is the same as the one in bug 1059116 comment 32. I wonder they are the same root cause. Is there a way to associate these crashes with the same bug for easier tracking?
Flags: needinfo?(ryanvm)
That crash signature is a generic "the harness killed the test" one. The easiest thing to do if you think they're the same is to add this test to the summary of that one so it comes up as a suggestion for it.
Flags: needinfo?(ryanvm)
Let's see if  I understand your statement clearly.

1. open a new bug with a summary like that of bug 832768 which include the names of the test cases.
2. edit the crash crash signature. (can you give an example about what this signature is like?)
3. should comment 24 or bug 1059116 comment 32 happen again, they should fall into the new bug.
(In reply to JW Wang [:jwwang] from comment #27)
> 1. open a new bug with a summary like that of bug 832768 which include the
> names of the test cases.

If you think there's a single underlying cause affecting multiple tests, this is the best thing to do, yes. The bug suggestions are based on filenames first and foremost.

> 2. edit the crash crash signature. (can you give an example about what this
> signature is like?)

I think you misunderstood me. My point is that the [@ libc.so + 0xc51c] crash is what you'll get from any test that times out and gets force-killed by the harness. So in an of itself, it isn't necessarily telling you much.

> 3. should comment 24 or bug 1059116 comment 32 happen again, they should
> fall into the new bug.

I'll leave that to you to decide. If you think it's a different issue than either one of the bugs already on file, then yes, it's probably best to track it in its own bug. Otherwise, we can just add test_mozaudiochannel.html to the summary of bug 1059116 and use that one. But you're in a better position to judge that than me :)
(In reply to Ryan VanderMeulen [:RyanVM UTC-4] from comment #28)
> I think you misunderstood me. My point is that the [@ libc.so + 0xc51c]
> crash is what you'll get from any test that times out and gets force-killed
> by the harness. So in an of itself, it isn't necessarily telling you much.

Simply telling [@ libc.so + 0xc51c] can be misleading. By crash signature I mean the whole stack trace such as:

00:07:06 INFO - Thread 0 (crashed)
00:07:06 INFO - 0 libc.so + 0xc51c
00:07:06 INFO - r4 = 0x00093620 r5 = 0x00000000 r6 = 0xffffffff r7 = 0x000000fc
00:07:06 INFO - r8 = 0x00000000 r9 = 0x00000014 r10 = 0x4428cdf4 fp = 0x40518430
00:07:06 INFO - sp = 0xbef932c8 lr = 0xa8121817 pc = 0xafd0c51c
00:07:06 INFO - Found by: given as instruction pointer in context
00:07:06 INFO - 1 libutils.so + 0x254bf
00:07:06 INFO - sp = 0xbef932e0 pc = 0xa81254c1
00:07:06 INFO - Found by: stack scanning
00:07:06 INFO - 2 libutils.so + 0x14cff
00:07:06 INFO - sp = 0xbef932f8 pc = 0xa8114d01
00:07:06 INFO - Found by: stack scanning
00:07:06 INFO - 3 libskia.so + 0x66792
00:07:06 INFO - sp = 0xbef93318 pc = 0xab166794
00:07:06 INFO - Found by: stack scanning
00:07:06 INFO - 4 libc.so + 0x1384b
00:07:06 INFO - sp = 0xbef93320 pc = 0xafd1384d
00:07:06 INFO - Found by: stack scanning
00:07:06 INFO - 5 libbinder.so + 0x13bfb
00:07:06 INFO - sp = 0xbef9332c pc = 0xa8213bfd
00:07:06 INFO - Found by: stack scanning
00:07:06 INFO - 6 libmozglue.so!arena_malloc [jemalloc.c:cd32febb260a : 1636 + 0x3]
00:07:06 INFO - sp = 0xbef93360 pc = 0x803284a7

I guess it is impossible for the current automation to scan the whole stack trace and decide into which bug this test failure should fall.
Back now that bug 1073615 has re-landed.
To debug this, you can uncomment the define for the lifecycle log in GraphDriver.cpp and MediaStreamGraph.cpp. Often the timeouts are because the audio stream did not start, or something like that. The lifecycle log will tell you everything to know about that.
https://treeherder.mozilla.org/ui/#/jobs?repo=try&revision=e14cdddbcf5f

With this push I want to try if increasing the timeout fixes the issue.
The crash is more about bug 1097721
Duplicate of this bug: 1120743
Summary: Intermittent test_mozaudiochannel.html | Test timed out. → Intermittent test_mozaudiochannel.html | Test timed out, | application timed out after 330 seconds with no output, | application ran for longer than allowed maximum time
Disabling this in the morning.
Flags: needinfo?(ryanvm)
Whiteboard: [test disabled on Android 2.3][leave open] → [test disabled on Android 2.3][leave open] [test disabled on Android 4.3]
Component: Audio/Video → Web Audio
Priority: -- → P3
Android 2.3 is no longer supported in Firefox 48+.

Test manifests were updated in bug 1251013.
Whiteboard: [test disabled on Android 2.3][leave open] [test disabled on Android 4.3] → [test disabled on Android 4.3]
Mass change P3->P4 to align with new Mozilla triage process.
Priority: P3 → P4
You need to log in before you can comment on or make changes to this bug.