845362 - TSan: Thread data race in lsm_increment_call_chn_cnt vs. lsm_get_available_line

Status: RESOLVED FIXED

(Core :: WebRTC, defect, P2)

Description

[Christoph Diehl [:posidron]]

Attachment: trace

During initial tests with ThreadSanitizer (LLVM version), we get a data race reported as described in the attached log. Trace was created on mozilla-central with changeset 122820:c233837cce08.

According to the TSan devs, most of the reported traces should be real data races, even though they can be "benign". We need to determine if the race can/should be fixed, or put on the ignore list. Even for benign races, TSan devs suggest to fix them (second priority), as they can also cause problems [1].

[1] http://software.intel.com/en-us/blogs/2013/01/06/benign-data-races-what-could-possibly-go-wrong

Comment 1

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

This looks like a real race, though it may not be an issue in practice (would need to understand this code better to say)

Comment 2

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

Note that it's a real race, but we may not be making use of this.

Comment 3

[Ethan Hugg [:ehugg]]

Attachment: Signaling - Remove max calls per line

Comment 4

[Ethan Hugg [:ehugg]]

Comment on attachment 732519 [details] [diff] [review]
Signaling - Remove max calls per line

Review of attachment 732519 [details] [diff] [review]:
-----------------------------------------------------------------

I recommend just removing the max-calls-per-line concept altogether.

Comment 5

[Adam Roach [:abr]]

Comment on attachment 732519 [details] [diff] [review]
Signaling - Remove max calls per line

Review of attachment 732519 [details] [diff] [review]:
-----------------------------------------------------------------

Except for the format string issue I mention below, this all looks good to me.

::: media/webrtc/signaling/src/sipcc/core/common/config_api.c
@@ +301,5 @@
>          }
>          table++;
>      }
>  
> +    debugif_printf("%s %s %s %s %s %s %s %s %s %s %s %s %s %s %s %s %s\n",

I count seventeen "%s" but only sixteen parameters.

Comment 6

[Ethan Hugg [:ehugg]]

https://hg.mozilla.org/integration/mozilla-inbound/rev/ba80ed4de343

Comment 7

[Ed Morley [:emorley]]

https://hg.mozilla.org/mozilla-central/rev/ba80ed4de343

Comment 8

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

Comment on attachment 732519 [details] [diff] [review]
Signaling - Remove max calls per line

[Approval Request Comment]
Bug caused by (feature/regressing bug #): N/A

User impact if declined: TSAN bugs are inherently risky and compiler/optimizer and runtime timing dependent.  Nuclear missiles could be launched (to borrow a phrase from the "there are no such things as benign data races" article.

Testing completed (on m-c, etc.): On m-c for a while.

Risk to taking this patch (and alternatives if risky): Minimal risk; it removes a feature of the imported signaling library we weren't using and had no intention to use.


String or IDL/UUID changes made by this patch: only debug log message format strings

Comment 9

[Alex Keybl [:akeybl]]

Comment on attachment 732519 [details] [diff] [review]
Signaling - Remove max calls per line

We won't track these unknown-criticality webrtc security issues, but will take the fixes up to Aurora.

Comment 10

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

https://hg.mozilla.org/releases/mozilla-aurora/rev/97a210433b0c