Open Bug 1975576 Opened 16 days ago Updated 6 days ago

Crash in [@ __if_indextoname] via NrIceCtx::StartGathering

Categories

(Core :: WebRTC: Networking, defect)

defect

Tracking

()

People

(Reporter: mccr8, Unassigned)

Details

(Keywords: crash, topcrash)

Crash Data

Crash report: https://crash-stats.mozilla.org/report/index/e16136bf-c417-46f0-bc84-ea6b30250703

Reason:

SIGSYS / SYS_SECCOMP

Top 10 frames:

0  libc.so.6  __GI___ioctl  /usr/src/debug/glibc/glibc/sysdeps/unix/sysv/linux/ioctl.c:36
1  libc.so.6  __if_indextoname  /usr/src/debug/glibc/glibc/sysdeps/unix/sysv/linux/if_index.c:231
2  libxul.so  set_ifname  dom/media/webrtc/transport/third_party/nICEr/src/stun/addrs-netlink.c:75
2  libxul.so  stun_convert_netlink  dom/media/webrtc/transport/third_party/nICEr/src/stun/addrs-netlink.c:133
2  libxul.so  stun_getaddrs_filtered  dom/media/webrtc/transport/third_party/nICEr/src/stun/addrs-netlink.c:251
3  libxul.so  nr_stun_get_addrs  dom/media/webrtc/transport/third_party/nICEr/src/stun/addrs.c:208
4  libxul.so  nr_stun_find_local_addresses  dom/media/webrtc/transport/third_party/nICEr/src/stun/stun_util.c:164
4  libxul.so  nr_ice_gather  dom/media/webrtc/transport/third_party/nICEr/src/ice/ice_ctx.c:871
5  libxul.so  mozilla::NrIceCtx::StartGathering(bool, bool)  dom/media/webrtc/transport/nricectx.cpp:934
6  libxul.so  mozilla::MediaTransportHandlerSTS::StartIceGathering(bool, bool, nsTArray<moz...  dom/media/webrtc/jsapi/MediaTransportHandler.cpp:920

This signature looks useless but it seems that it isn't that uncommon and they all have this same stack. It is a null deref.

It looks like this crash is Nightly only. It first showed up in 140a, in the 20250523091654 build. The crashes are all in the socket process.

Only thing I can see that might be involved (and landed near the target 2025-05-23) is bug 1954423. Byron, any thoughts here?

Flags: needinfo?(docfaraday)

The bug is linked to a topcrash signature, which matches the following criterion:

  • Top 10 desktop browser crashes on nightly

For more information, please visit BugBot documentation.

Keywords: topcrash

So this is nightly only on multiple versions of nightly (140, 141, and 142). It has never occured on 140 beta/release or 141 beta it seems. Bug 1954423 isn't restricted to nightly in any way, I don't see how this could be caused by bug 1954423, and we're still a few days off (bad builds start on May 23, with plenty of crashes, but bug 1954423 landed a few days before that).

A large majority of these are happening multiple times on the same install. Arch linux is waaaaaay overrepresented (there is a large number of Fedora 42 crashes up until mid-June, and then it becomes almost entirely Arch). Maybe that's because most other distros don't end up using nightly? Or maybe Fedora 42 and Arch users are the main Firefox users on linux? Not sure about that.

Kernel build dates look pretty recent for each crash report; all of these users had updated their kernel within a month or two. Maybe there was a particular kernel patch that interacts poorly with Firefox, or maybe changed the signature of this crash?

Flags: needinfo?(docfaraday)
You need to log in before you can comment on or make changes to this bug.