This bug is for crash report bp-096e55df-ca90-463d-82df-23bcd0190524.

Top 10 frames of crashing thread:

0 xul.dll mozilla::net::HttpBaseChannel::SetReferrerInfo netwerk/protocol/http/HttpBaseChannel.cpp:1581
1 xul.dll nsCORSListenerProxy::StartCORSPreflight netwerk/protocol/http/nsCORSListenerProxy.cpp:1546
2 xul.dll nsresult mozilla::net::nsHttpChannel::ConnectOnTailUnblock netwerk/protocol/http/nsHttpChannel.cpp:779
3 xul.dll nsresult mozilla::net::nsHttpChannel::Connect netwerk/protocol/http/nsHttpChannel.cpp:713
4 xul.dll nsresult mozilla::net::nsHttpChannel::ContinueOnBeforeConnect netwerk/protocol/http/nsHttpChannel.cpp:662
5 xul.dll nsresult mozilla::net::nsHttpChannel::OnBeforeConnect netwerk/protocol/http/nsHttpChannel.cpp:586
6 xul.dll nsresult mozilla::net::nsHttpChannel::ContinueBeginConnectWithResult netwerk/protocol/http/nsHttpChannel.cpp:6950
7 xul.dll nsresult mozilla::net::nsHttpChannel::BeginConnectActual netwerk/protocol/http/nsHttpChannel.cpp:6804
8 xul.dll void std::_Func_impl_no_alloc<`lambda at z:/task_1558355121/build/src/netwerk/protocol/http/nsHttpChannel.cpp:6715:23', void>::_Do_call 
9 xul.dll nsresult mozilla::detail::RunnableFunction<`lambda at z:/task_1558355121/build/src/netwerk/url-classifier/AsyncUrlChannelClassifier.cpp:797:13'>::Run xpcom/threads/nsThreadUtils.h:562

this crash signature is newly showing up in 68.0b - in low volume though and so far only from users of devedition builds.
this might be related to the changes from bug 1532318.

I see the crash might not to be related to bug 1532318. At the first look, it crashed at this point:
https://searchfox.org/mozilla-central/rev/4606c7974a68cab416c038acaedcae49eed93822/netwerk/protocol/http/HttpBaseChannel.cpp#1581

if this is correct, we called this function after connect, I don't change any of that logic in bug 1532318.
Or another thing may happen, the memory of this channel is somehow inaccessible.

Well, I looked at the crash history and I could see this bug happened before but with different crash signature:
https://crash-stats.mozilla.org/signature/?signature=mozilla%3A%3Anet%3A%3AHttpBaseChannel%3A%3ASetReferrerWithPolicy&date=%3E%3D2018-11-24T19%3A52%3A00.000Z&date=%3C2019-05-24T19%3A52%3A00.000Z&_columns=date&_columns=product&_columns=version&_columns=build_id&_columns=platform&_columns=reason&_columns=address&_columns=install_time&_columns=startup_crash&_sort=-date&page=1#reports

I think I should change the component to necko and cc someone may have a good idea on this bug

It seems that we're accessing a null pointer here:
https://searchfox.org/mozilla-central/rev/7556a400affa9eb99e522d2d17c40689fa23a729/netwerk/protocol/http/nsCORSListenerProxy.cpp#1507,1541,1546

Presumably we only need to check for that the preCh and reqCh are not null before using them.
Thomas, do you want to take the bug?

https://hg.mozilla.org/mozilla-central/rev/173a179ae14b

Want to request uplift to 68?

It is easy and low risk to uplift. Thanks.
And it is more correct to set affected version is: the bug existed for a long time ago, with different crash signature. So it would affected to 67 and earlier

Comment on attachment 9068312 [details]
Bug 1554289 - Add non-null checks around assignment referrerInfo to preflight HTTP channel

Beta/Release Uplift Approval Request

• User impact if declined: Low rate crash
• Is this code covered by automated tests?: No
• Has the fix been verified in Nightly?: No
• Needs manual test from QE?: No
• If yes, steps to reproduce:
• List of other uplifts needed: None
• Risk to taking this patch: Low
• Why is the change risky/not risky? (and alternatives if risky): Non-null check only
• String changes made/needed: No

Comment on attachment 9068312 [details]
Bug 1554289 - Add non-null checks around assignment referrerInfo to preflight HTTP channel

add null checks to avoid crashes, approved for 68.0b8

https://hg.mozilla.org/releases/mozilla-beta/rev/4bd74b23ffb6