805729 - WebRTC crash [@nr_ice_candidate_pair_stun_cb]

Status: RESOLVED FIXED

(Core :: WebRTC: Networking, defect, P1)

Description

[Christoph Diehl [:posidron]]

Attachment: callstack

Reproducible use-after-free bug, couldn't reproduce with a single testcase yet but it pops up every now and then with the same callstack.


alloc: media/mtransport/third_party/nICEr/src/ice/ice_candidate_pair.c:63

int nr_ice_candidate_pair_create(nr_ice_peer_ctx *pctx, nr_ice_candidate *lcand,nr_ice_candidate *rcand,nr_ice_cand_pair **pairp)
  {
[...]
    if(!(pair=RCALLOC(sizeof(nr_ice_cand_pair))))
      ABORT(R_NO_MEMORY);
[...]


free: media/mtransport/third_party/nICEr/src/ice/ice_candidate_pair.c:175

int nr_ice_candidate_pair_destroy(nr_ice_cand_pair **pairp)
  {
[...]
    RFREE(pair);
[...]


re-use: media/mtransport/third_party/nICEr/src/ice/ice_candidate_pair.c:200

[...]
    r_log(LOG_ICE,LOG_DEBUG,"ICE-PEER(%s)/STREAM(%s): STUN cb on pair %s",
      pair->pctx->label,pair->local->stream->label,pair->as_string);
[...]


Tested on m-central with changeset: 111360:58c8080a1a7c

Comment 1

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

ekr: same question - have you looked at this, and if so, is this also expected to be fixed by the lock patch?  Thanks.

Comment 2

[Jason Smith [:jsmith]]

Not crashtest worthy at the moment, as it needs a clearer consistent testcase defined.

Comment 3

[Daniel Veditz [:dveditz] back 2026-04-08]

Adding a needinfo?ekr for comment 1

Comment 4

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

ekr: bump

Comment 5

[Eric Rescorla (:ekr)]

All of these events are on the STS thread, so I doubt that any locks would fix it.

I'm not sure what the problem is, but presumably it's a failure to cancel some timer.

Comment 6

[Eric Rescorla (:ekr)]

A lot of things have changed. Are you still seeing this?

Comment 7

[Maire Reavy [:mreavy]]

cdiehl - can you retest this for us?  Thanks.

Comment 8

[Eric Rescorla (:ekr)]

cdiehl: if you do repro, please report the timer duration of the timer in question here.

The field is timer.mDelay.

Comment 9

[Eric Rescorla (:ekr)]

jesup: I think this is probably an NR_ASYNC_SCHEDULE non-cancellation issue, but I would like to verify before we start fixing.

Comment 10

[Christoph Diehl [:posidron]]

I haven't seen this crash for a while but if it occurs again I will let you know.

Comment 11

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

Given it hasn't been seen recently, do we believe this has been fixed along the way by other fixes?  Is there any way to verify that or to add assertions to catch this if it's still happening?

Comment 12

[Eric Rescorla (:ekr)]

I suspect that it has not been fixed because we know that ASYNC_SCHEDULE is still a potential issue. It's probably just pretty hard to reproduce from JS.

Comment 13

[David Bolter [:davidb] (NeedInfo me for attention)]

Resetting tracking flags.

Comment 14

[Eric Rescorla (:ekr)]

I believe this is now fixed by 825651. I'm marking as resolved. Please reopen if you see it again,