1384603 - Crash in nsDocumentOpenInfo::OnStartRequest

Status: RESOLVED WORKSFORME

(Thunderbird :: Search, defect)

Description

[Bob Clary [:bc] (inactive)]

This bug was filed from the Socorro interface and is 
report bp-1166f302-3574-4a0a-b71b-efc5a0170726.
=============================================================

1. search newsgroups.
2. double click message in search results.
3. crash.

reproducible bp-7a68506e-8541-48c6-8c7a-4064e0170726

My specific search was for subject Taskcluster with age < 90 days. I clicked on Changes to tools.taskcluster.net on 2017/06/30 in mozilla.tools.taskcluster.

Comment 1

[Jorg K (CEST = GMT+2)]

You mean the one from [e-mail]? What do you mean by "search newsgroups"? I searched for subject Taskcluster in mozilla.tools.taskcluster and double-clicking onto the message doesn't give a crash.

Comment 2

[Bob Clary [:bc] (inactive)]

I originally had selected the news.mozilla.org folder and searched from there. I just did a search from the mozilla.tools.taskcluster and clicked the first message to get bp-85896197-3c71-4168-b26b-270cc0170726 and crashed [@ mozilla::net::nsStreamListenerTee::OnStartRequest ]

I tried to reproduce it yet again after restarting and it doesn't reproduce at the moment. I've tried several times now. I don't know why it won't reproduce anymore.

I should have mentioned this is with Daily 56.0 on Fedora 26 x86_64.

Comment 3

[Jorg K (CEST = GMT+2)]

(In reply to Bob Clary [:bc:] from comment #2)
> I tried to reproduce it yet again after restarting and it doesn't reproduce
> at the moment.
I do ;-) Most crashes are due to some erroneous memory access and it's pretty much a random effect since is depends on the (random) content of the memory that shouldn't have been accessed in the first place. Those crashes are very hard if not (almost) impossible to find.

Comment 4

[Wayne Mery (:wsmwk)]

nsDocumentOpenInfo::OnStartRequest bp-7a68506e-8541-48c6-8c7a-4064e0170726
mozilla::net::nsStreamListenerTee::OnStartRequest bp-85896197-3c71-4168-b26b-270cc0170726
0	libxul.so	mozilla::net::nsStreamListenerTee::OnStartRequest	netwerk/base/nsStreamListenerTee.cpp:25
1	libxul.so	nsMsgProtocol::OnStartRequest	/builds/slave/tb-c-cen-l64-ntly-000000000000/build/mailnews/base/util/nsMsgProtocol.cpp:319
2	libxul.so	nsNNTPProtocol::LoadUrl	/builds/slave/tb-c-cen-l64-ntly-000000000000/build/mailnews/news/src/nsNNTPProtocol.cpp:1080
3	libxul.so	nsMsgProtocol::AsyncOpen	/builds/slave/tb-c-cen-l64-ntly-000000000000/build/mailnews/base/util/nsMsgProtocol.cpp:549
4	libxul.so	nsNNTPProtocol::OnCacheEntryAvailable	/builds/slave/tb-c-cen-l64-ntly-000000000000/build/mailnews/news/src/nsNNTPProtocol.cpp:802
5	libxul.so	mozilla::net::CacheEntry::InvokeAvailableCallback	netwerk/cache2/CacheEntry.cpp:891
6	libxul.so	mozilla::net::CacheEntry::InvokeCallback	netwerk/cache2/CacheEntry.cpp:813
7	libxul.so	mozilla::net::CacheEntry::InvokeCallbacks	netwerk/cache2/CacheEntry.cpp:679
8	libxul.so	mozilla::net::CacheEntry::InvokeCallbacks	netwerk/cache2/CacheEntry.cpp:619
9	libxul.so	mozilla::net::CacheEntry::Open	netwerk/cache2/CacheEntry.cpp:338
10	libxul.so	mozilla::net::CacheEntry::AsyncOpen	netwerk/cache2/CacheEntry.cpp:312
11	libxul.so	mozilla::net::CacheStorage::AsyncOpenURI	netwerk/cache2/CacheStorage.cpp:112
12	libxul.so	nsNNTPProtocol::OpenCacheEntry	/builds/slave/tb-c-cen-l64-ntly-000000000000/build/mailnews/news/src/nsNNTPProtocol.cpp:841
13	libxul.so	nsNNTPProtocol::AsyncOpen	/builds/slave/tb-c-cen-l64-ntly-000000000000/build/mailnews/news/src/nsNNTPProtocol.cpp:886
14	libxul.so	nsNNTPProtocol::AsyncOpen2	/builds/slave/tb-c-cen-l64-ntly-000000000000/build/mailnews/news/src/nsNNTPProtocol.cpp:897
15	libxul.so	nsURILoader::OpenURI	uriloader/base/nsURILoader.cpp:857

Comment 5

[Wayne Mery (:wsmwk)]

Have you been doing steps like this recently and not crashing?  If yes, and you can reliably reproduce this crash, then perhaps a recent regression is involved.  because your recent crash history [1] (excluding the shutdown crashes [2]) doesn't include any crashes like this.

[1]
bp-85896197-3c71-4168-b26b-270cc0170726	2017-07-26 19:24:34 	mozilla::net::nsStreamListenerTee::OnStartRequest   Add term
bp-7a68506e-8541-48c6-8c7a-4064e0170726	2017-07-26 15:01:07 	nsDocumentOpenInfo::OnStartRequest   Add term
bp-1166f302-3574-4a0a-b71b-efc5a0170726	2017-07-26 14:55:11 	nsDocumentOpenInfo::OnStartRequest   Add term
bp-bb5dfb3b-0cac-4c2c-9e88-8ffc40170609	2017-06-09 14:12:05 	morkRow::GetColumnAtom   Add term 

[2]
bp-54f7b7ff-f3aa-4eac-868b-5259e0170713	2017-07-13 13:07:01 	AsyncShutdownTimeout | AddonManager: Waiting for providers to shut down. | EnvironmentAddonBuilder   Add term
bp-67541c99-f9ef-4bc7-9e7d-03bec0170713	2017-07-13 13:00:42 	AsyncShutdownTimeout | AddonManager: Waiting for providers to shut down. | EnvironmentAddonBuilder   Add term
bp-e2258f71-afc8-4e88-8360-c65f90170712	2017-07-12 19:51:29 	AsyncShutdownTimeout | AddonManager: Waiting for providers to shut down. | EnvironmentAddonBuilder   Add term
bp-d52ae1ea-b16e-43ab-9749-c78ee0170711	2017-07-11 12:50:43 	AsyncShutdownTimeout | AddonManager: Waiting for providers to shut down. | EnvironmentAddonBuilder   Add term
bp-80fe824e-8059-4b81-a5b8-004400170710	2017-07-10 13:22:35 	AsyncShutdownTimeout | AddonManager: Waiting for providers to shut down. | EnvironmentAddonBuilder   Add term

Comment 6

[Bob Clary [:bc] (inactive)]

No, I normally don't search this way. Most of the time I use quick filters, saved searches or a combination of the two. I filed since at least initially it was easily reproducible but I can't reproduce any more. :-(

Comment 7

[Bob Clary [:bc] (inactive)]

Got another one with today's build: bp-5f7da009-ee16-437e-92c4-d6f220170728

Comment 8

[Wayne Mery (:wsmwk)]

Have you crashed in the last 2-3 months?

I see only 3 crashes withthese signatures in the last 3 months, two of which are 
bp-4b3e12eb-e4be-4b1a-9117-70ab20180831 60.0b10 
bp-9e016401-f798-4406-a6a7-dd6cf0180627 52.5.0

Comment 9

[Bob Clary [:bc] (inactive)]

I'm on 60 on Fedora 28 now and can't reproduce. Let's WFM this.