This bug was filed from the Socorro interface and is report bp-b62c462a-1d88-4d29-b507-4390a2161016. ============================================================= Crashing Thread (5) Frame Module Signature Source 0 xul.dll mozilla::net::nsSocketTransportService::DoPollIteration(mozilla::BaseTimeDuration<mozilla::TimeDurationValueCalculator>*) netwerk/base/nsSocketTransportService2.cpp:1140 1 xul.dll mozilla::net::nsSocketTransportService::Run() netwerk/base/nsSocketTransportService2.cpp:894 2 xul.dll nsThread::ProcessNextEvent(bool, bool*) xpcom/threads/nsThread.cpp:1076 3 xul.dll NS_ProcessNextEvent(nsIThread*, bool) xpcom/glue/nsThreadUtils.cpp:290 4 xul.dll mozilla::ipc::MessagePumpForNonMainThreads::Run(base::MessagePump::Delegate*) ipc/glue/MessagePump.cpp:354 5 xul.dll MessageLoop::RunHandler() ipc/chromium/src/base/message_loop.cc:225 6 xul.dll MessageLoop::Run() ipc/chromium/src/base/message_loop.cc:205 7 xul.dll nsThread::ThreadFunc(void*) xpcom/threads/nsThread.cpp:469 8 nss3.dll _PR_NativeRunThread nsprpub/pr/src/threads/combined/pruthr.c:397 9 nss3.dll pr_root nsprpub/pr/src/md/windows/w95thred.c:95 10 ucrtbase.dll _crt_at_quick_exit 11 kernel32.dll BaseThreadInitThunk 12 ntdll.dll __RtlUserThreadStart 13 ntdll.dll _RtlUserThreadStart this is a cross platform crash signature that started popping up in firefox 49 and subsequent builds. it's quite low volume though (only 0.02% of browser crashes in 50.0b at the moment for example).

I do not know how this crash happens. I do not see anything obvious. Many, but not all have inproc_agent.dll (this belongs to kaspersky but that should not cause the problem) We cash in DoPollIteration in different places, on read and write. we are not in shutdown.

I do not see the real reason why it is crashing. It cashes, most of the times, at: https://hg.mozilla.org/releases/mozilla-beta/annotate/6efc0964ec62/netwerk/base/nsSocketTransportService2.cpp#l1140 if (mTelemetryEnabledPref) { mTelemetryEnabledPref is atomic! This has increased from 1 or less crashes per day to ca.25 per day on 50b7 and 50b8. This is just a telemetry that we can remove as a quick fix. But I o not know what is the real cause. philipp, do you know is it relevant to fix this?

(In reply to Dragana Damjanovic [:dragana] from comment #2) > philipp, do you know is it relevant to fix this? only at a very low priority i'd say. now that i look closer at the spike in b7&b8, this increased number of reports seems to come mainly from intel cpu devices that are affected by the intermittent pgo bug 1296630, so that's not a necko-specific underlying cause there...

(In reply to [:philipp] from comment #3) > (In reply to Dragana Damjanovic [:dragana] from comment #2) > > philipp, do you know is it relevant to fix this? > only at a very low priority i'd say. > now that i look closer at the spike in b7&b8, this increased number of > reports seems to come mainly from intel cpu devices that are affected by the > intermittent pgo bug 1296630, so that's not a necko-specific underlying > cause there... This can be related. Thanks.

Too late for firefox 52, mass-wontfix.

Bulk change to priority: https://bugzilla.mozilla.org/show_bug.cgi?id=1399258

Moving to p3 because no activity for at least 1 year(s). See https://github.com/mozilla/bug-handling/blob/master/policy/triage-bugzilla.md#how-do-you-triage for more information