806826 - WebRTC possible data race with sip_process_int_msg vs. SIPTaskSendMsg

Status: RESOLVED INVALID

(Core :: WebRTC: Signaling, defect)

Description

[Christoph Diehl [:posidron]]

Attachment: callstack

media/webrtc/signaling/src/sipcc/core/sipstack/sip_platform_task.c:375
            cprReleaseSysHeader(syshdr);

media/webrtc/signaling/src/sipcc/core/sipstack/ccsip_task.c:325
    syshdr->Cmd = cmd;

Tested with m-c changeset: 111684:e19e170d2f6d

Comment 1

[Christoph Diehl [:posidron]]

In one thread we trying to free 'syshdr' cprReleaseSysHeader() and in the other one we are trying to write to a syshdr member. 
No locks involved; the TSan mode was pure-happens-before might be false-positive.

Comment 2

[Eric Rescorla (:ekr)]

I think this is another false positive. If I am reading the code correctly, the assignment happens in a block which is allocated in thread 1 and then pushed onto thread 2, where the free happens


I wonder if tsan knows that network writes are synchronization checkpoints

Comment 3

[Christoph Diehl [:posidron]]

TSan instruments all code except the code which is explicitly ignored.

Comment 4

[Eric Rescorla (:ekr)]

Right, but I don't think that's the answer to the question.

Basically, if you have two file descriptors, fd1, fd2 and a shared variable X
which are the opposite ends of a pipe, the following sequence is safe

Thread 1:
X = 9;
send(fd1, ...)


Thread 2:
recv(fd2, ....)
read X;

Does TSAN know this?

Comment 5

[Christoph Diehl [:posidron]]

If there is a situation where X gets read/written to at the same time, TSan would mark it as a possible race condition. It's then our job to identify if it is false positive or not. In case it is a false positive we can suppress this condition with a rule.

Comment 6

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

Let's add this to the list of suppressions, as it appears to be a false positive.

When that's done we'll close this.

-> cdiehl