Closed Bug 1307696 Opened 8 years ago Closed 8 years ago

Intermittent TEST-UNEXPECTED-TIMEOUT | dom/media/tests/mochitest/test_peerConnection_addSecondAudioStream.html | application timed out after 330 seconds with no output

Categories

(Core :: WebRTC, defect, P3)

Product:
Core
Component:
WebRTC
Type:
defect

Tracking

()

Status:
RESOLVED DUPLICATE of bug 1304519

People

(Reporter: intermittent-bug-filer, Unassigned)

References

Details

(Keywords: intermittent-failure) 

This one shows a MOZ_CRASH before the IPC error:

> 21:16:15     INFO -  Hit MOZ_CRASH() at /builds/slave/autoland-m64-d-000000000000000/build/src/memory/mozjemalloc/jemalloc.c:1631
> 21:16:15     INFO -  ###!!! [Parent][MessageChannel] Error: (msgtype=0x300084,name=PBrowser::Msg_Destroy) Channel error: cannot send/recv
Rank: 35
Depends on: 1306856
Priority: -- → P3
Neat. It crashed when collecting Telemetry stats in STS - or more precisely when trying to re-allocate memory while trying to gather the stats:

21:22:15     INFO -   0  libmozglue.dylib!jemalloc_crash [jemalloc.c:86597cc0234a : 1631 + 0x0]
21:22:15     INFO -   1  libmozglue.dylib!arena_dalloc [jemalloc.c:86597cc0234a : 4677 + 0x5]
21:22:15     INFO -   2  libmozglue.dylib!je_realloc [jemalloc.c:86597cc0234a : 4760 + 0x5]
21:22:15     INFO -   3  libmozglue.dylib!moz_xrealloc [mozalloc.cpp:86597cc0234a : 105 + 0x5]
21:22:15     INFO -   4  XUL!nsTArrayInfallibleAllocator::ResultTypeProxy nsTArray_base<nsTArrayInfallibleAllocator, nsTArray_CopyWithMemutils>::EnsureCapacity<nsTArrayInfallibleAllocator>(unsigned long, unsigned long) [nsTArray.h:86597cc0234a : 209 + 0xb]
21:22:15     INFO -   5  XUL!mozilla::Telemetry::Accumulation* nsTArray_Impl<mozilla::Telemetry::Accumulation, nsTArrayInfallibleAllocator>::AppendElement<mozilla::Telemetry::Accumulation, nsTArrayInfallibleAllocator>(mozilla::Telemetry::Accumulation&&) [nsTArray.h:86597cc0234a : 2073 + 0x5]
21:22:15     INFO -   6  XUL!(anonymous namespace)::internal_RemoteAccumulate(mozilla::Telemetry::ID, unsigned int) [TelemetryHistogram.cpp:86597cc0234a : 1352 + 0x5]
21:22:15     INFO -   7  XUL!(anonymous namespace)::internal_Accumulate(mozilla::Telemetry::ID, unsigned int) [TelemetryHistogram.cpp:86597cc0234a : 1382 + 0xa]
21:22:15     INFO -   8  XUL!TelemetryHistogram::Accumulate(mozilla::Telemetry::ID, unsigned int) [TelemetryHistogram.cpp:86597cc0234a : 2152 + 0xa]
21:22:15     INFO -   9  XUL!mozilla::net::nsSocketTransportService::Run() [nsSocketTransportService2.cpp:86597cc0234a : 908 + 0x10]

Which raises the question: should Telemetry pref actually be turned on for test runs?

But looking at the release assert which kills things here:
https://dxr.mozilla.org/mozilla-central/rev/c7d62e6d052c5d2638b08d480a720254ea09ff2d/memory/mozjemalloc/jemalloc.c#4677
I'm guessing that actually something stomps over memory areas here. Which would also explain why we see lots of different stack traces... fun times...
And this is showing up in the log after the timeout because of e10s?

I think I've seen similar stacks in a couple of try runs as well (mentioning TelemetryHistogram).
There we go. And it's supposedly fixed.
Blocks: 1218576
Status: NEW → RESOLVED
Closed: 8 years ago
No longer depends on: 1306856
Resolution: --- → DUPLICATE
(In reply to Andreas Pehrson [:pehrsons] (Telenor) from comment #3)
> And this is showing up in the log after the timeout because of e10s?

The memory assertion kicks in and crashes the process. This then results sometimes in e10s errors. Then the whole things still sits there and waits for the test timeout. Why? I have no real clue.
Once the framework realizes the timeout it dumps all mochitest log messages left in its buffers and then after things shut down, the stack traces gets analyzed and written to the log.
You need to log in before you can comment on or make changes to this bug.