800931 - WebRTC Assertion failure: stream, at /media/webrtc/signaling/src/media/VcmSIPCCBinding.cpp:595

Status: RESOLVED DUPLICATE of bug 820671

(Core :: WebRTC: Signaling, defect, P2)

Description

[Christoph Diehl [:posidron]]

Attachment: NSPR_LOG_MODULES

I get this failure during the fuzz run quite often but testing the crash with a single testcase produces the same assertion failure as in bug 799419.

changeset:   110066:eeba6e117081
tag:         tip
user:        EKR <[e-mail]>
date:        Tue Oct 09 12:29:01 2012 -0700
files:       media/webrtc/signaling/src/media/VcmSIPCCBinding.cpp
description:
Bug 792811 - Check creation of WebRTC transportflows r=jesup

Comment 1

[Henrik Skupin [:whimboo][⌚️UTC+2]]

Christoph, does this assertion cause a crash in a non-debug build?

Comment 2

[Christoph Diehl [:posidron]]

Have not tested it with a non-debug build. I could do so in the next days after some patches landed. This happened during fuzzing SDP.

Comment 3

[Christoph Diehl [:posidron]]

I have not seen this failure while fuzzing m-c changeset: 112919:ea5c4c1b0edf with a opt-debug-asan build. MOZ_ASSERT is only triggered in debug builds, right? In that case I assume it won't fail in non-debug builds at least not with an assertion failure.

Comment 4

[Randell Jesup [:jesup] (needinfo me)]

This appears to have moved to line 560 (the only MOZ_ASSERT(stream))

MOZ_ASSERT is a debug-only thing.

We should cleanly exit the routine in a non-debug build (it does "if (!stream) return;" basically.)  So it's asserting that something is wrong, but in production it should just cleanly fail to return any useful ICE info.

It sets *default_portp = -1 before making these tests (which is the failure flag)

Comment 5

[Randell Jesup [:jesup] (needinfo me)]

Now (with ekr's Dispatch patch) line 448.

a) does this still happen, and if so, does it with the Dispatch patch?
b) is this really an ASSERTable issue, or is it ok to just fail it here?

Comment 6

[Eric Rescorla (:ekr)]

1. I believe this will still happen with the current Dispatch patch
2. It should not happen if we add the patch to have the PCWrapper be empty if !media
3. Yes, we should assert if we add patch #2, since the streams should exist.

Comment 7

[Randell Jesup [:jesup] (needinfo me)]

Believed fixed by bug 820671; please reopen if it recurs