1516636 - Crash in <name omitted> | mozilla::places::(anonymous namespace)::VisitedQuery::Start

Status: RESOLVED INCOMPLETE

(Thunderbird :: General, defect)

Description

[Darkspirit]

This bug was filed from the Socorro interface and is
report bp-c8f6d324-04c0-48bb-8ddd-a45c60181228.
=============================================================

Top 10 frames of crashing thread:

0 libxul.so <name omitted> ipc/glue/URIUtils.cpp:47
1 libxul.so mozilla::places:: toolkit/components/places/History.cpp:380
2 libxul.so mozilla::places::History::RegisterVisitedCallback toolkit/components/places/History.cpp:2138
3 libxul.so mozilla::dom::Link::LinkState const dom/base/Link.cpp:372
4 libxul.so nsIDocument::FlushPendingLinkUpdates dom/base/nsDocument.cpp:8852
5 libxul.so mozilla::detail::RunnableMethodImpl<nsIDocument*, void  xpcom/threads/nsThreadUtils.h:1106
6 libxul.so <name omitted> xpcom/threads/nsThreadUtils.cpp:317
7 libxul.so nsThread::ProcessNextEvent xpcom/threads/nsThread.cpp:1157
8 libxul.so NS_ProcessNextEvent xpcom/threads/nsThreadUtils.cpp:468
9 libxul.so mozilla::ipc::MessagePump::Run ipc/glue/MessagePump.cpp:88

=============================================================

Comment 1

[Wayne Mery (:wsmwk)]

Jan Andre, what were you doing at the time of the crash?
And do you have other crash IDs?

The oldest buildid is 20181219083518 bp-fd24abd7-997f-4865-8a2e-14e6c0181228 
But the crashes didn't start until Dec 28.
I'd imagine this is a regression

Comment 2

[Darkspirit]

All of these crashes seem to be mine. I have no STR yet, but will look for one. The "regression" might be "me switching to Daily and using a custom config". (I am probably the only Thunderbird user with WebRender, GPU process and other things enabled.)

Comment 3

[Jorg K (CEST = GMT+2)]

This is related to URI handling since the crash is in ipc/glue/URIUtils.cpp:47 which is:

  nsCOMPtr<nsIIPCSerializableURI> serializable = do_QueryInterface(aURI);
  if (!serializable) {
47  MOZ_CRASH("All IPDL URIs must be serializable!");
  }

Same crash location as in bug 1515337. So it looks like some other of our "Thunderbird" URLs needs to be made serialisable as well. After fixing mailbox, IMAP, NNTP, etc. there are address book, LDAP and mailto: left. So any address book action, or LDAP or perhaps clicking a mailto: link?

Comment 4

[Darkspirit]

I open my spiegel.de RSS feed, click on uBlock Origin on the toolbar and then on its settings symbol. The extension process (extensions.webextensions.remote;true) crashes. uBlock Origin doesn't reliably work anyway: Most times it's just as if no address was opened at all.

Comment 5

[Jorg K (CEST = GMT+2)]

Hmm, quite a twisted setup, not as straight forward as bug 1515337. We need to work out which URL type causes the crash. Maybe :darktrojan can assist :darkspirit here, or else I'll take a look later.

Comment 6

[Jorg K (CEST = GMT+2)]

OK, I've returned to try this. I don't know whether spiegel.de is a paying service, so I tried this feed instead:
http://feeds.arstechnica.com/arstechnica/index

I've installed "uBlock Origin" from here:
https://addons.mozilla.org/en-GB/firefox/addon/ublock-origin/
Curiously enough, it worked.

So then I clicked on the "uBlock Origin on the toolbar" and a panel opens. There is no "settings symbol". The closest I could see was the dashboard, the icon has three sliders, and such icons are usually used for settings. That opens a new tab and in there I have "Settings", "Filter list", "My filters", etc. No crash.

So what am I doing differently? Can you please give more details on how to reproduce the crash.

Comment 7

[Wayne Mery (:wsmwk)]

same as bug 1353704 ?

Comment 8

[Wayne Mery (:wsmwk)]

Jan, can you post other crash report IDs?

Comment 9

[Jorg K (CEST = GMT+2)]

(In reply to Wayne Mery (:wsmwk) from comment #7)

same as bug 1353704 ?

Not that I can see. What makes you think that?

Comment 10

[Wayne Mery (:wsmwk)]

What makes you think that?

Not by anything in the stack. Just the fact that it may be RSS related

Comment 11

[Darkspirit]

Sorry, I still have to find reliable STR with mozregression. So far, it hasn't happened again.

Comment 12

[Wayne Mery (:wsmwk)]

Given this hasn't shown up in betas, and we don't have a testcase, it seems unlikely we'd make further progress.

If you do come up with something definitive please reopen the bug.