Crash in AsyncShutdownTimeout | places-will-close-connection | PlacesUtils read-only connection closing as part of Places shutdown

NEW
Unassigned
(NeedInfo from)

Status

()

defect
P3
critical
2 years ago
14 hours ago

People

(Reporter: alex_mayorga, Unassigned, NeedInfo)

Tracking

(4 keywords)

50 Branch
x86
Windows 10
Points:
---

Firefox Tracking Flags

(firefox50 wontfix, firefox51 wontfix, firefox52 wontfix, firefox-esr60 affected, firefox53 wontfix, firefox56 wontfix, firefox57 wontfix, firefox58 wontfix, firefox59 wontfix, firefox60 wontfix, firefox61 wontfix, firefox62 wontfix, firefox63- wontfix, firefox64- fix-optional, firefox65- fix-optional, firefox66 fix-optional)

Details

(crash signature)

Reporter

Description

2 years ago
This bug was filed from the Socorro interface and is 
report bp-cfb6a35f-2194-4263-90fe-882912161228.
=============================================================

¡Hola!

Found about this type of crash form https://support.mozilla.org/en-US/questions/1152126

There are 246 in the past week at https://crash-stats.mozilla.com/signature/?product=Firefox&signature=AsyncShutdownTimeout%20%7C%20places-will-close-connection%20%7C%20PlacesUtils%20read-only%20connection%20closing%20as%20part%20of%20Places%20shutdown

Filing it FWIW.

¡Gracias!
Reporter

Comment 1

2 years ago
Crashing Thread (0)
Frame 	Module 	Signature 	Source
0 	mozglue.dll 	mozalloc_abort(char const* const) 	memory/mozalloc/mozalloc_abort.cpp:33
1 	xul.dll 	NS_DebugBreak 	xpcom/base/nsDebugImpl.cpp:436
2 	xul.dll 	nsDebugImpl::Abort(char const*, int) 	xpcom/base/nsDebugImpl.cpp:146
3 	xul.dll 	NS_InvokeByIndex 	xpcom/reflect/xptcall/md/win32/xptcinvoke_asm_x86_msvc.asm:54
4 	xul.dll 	XPCWrappedNative::CallMethod(XPCCallContext&, XPCWrappedNative::CallMode) 	js/xpconnect/src/XPCWrappedNative.cpp:1361
5 	xul.dll 	XPC_WN_CallMethod(JSContext*, unsigned int, JS::Value*) 	js/xpconnect/src/XPCWrappedNativeJSOps.cpp:1128
6 	xul.dll 	js::InternalCallOrConstruct(JSContext*, JS::CallArgs const&, js::MaybeConstruct) 	js/src/vm/Interpreter.cpp:453
7 	xul.dll 	InternalCall 	js/src/vm/Interpreter.cpp:498
8 		@0x1
Too late for firefox 52, mass-wontfix.
Duplicate of this bug: 1402103
Severity: critical → normal
Priority: -- → P3
Updating bug with additional signature as well as marking affected branches.
Crash Signature: [@ AsyncShutdownTimeout | places-will-close-connection | PlacesUtils read-only connection closing as part of Places shutdown] → [@ AsyncShutdownTimeout | places-will-close-connection | PlacesUtils read-only connection closing as part of Places shutdown] [@ AsyncShutdownTimeout | Places Connection shutdown | PlacesUtils read-only connection closing as part of Places shutdown ]
This is the #3 topcrash on beta 62. It's also a very high volume crash on release 61. 
Nathan, might it be worth taking another look at this?
Flags: needinfo?(nfroyd)
Component: XPCOM → Places
Product: Core → Toolkit
I will defer to asuth or mak on this one.

I'm really curious what places is doing here.  Looking through a couple of crash reports, the Mac reports have (sort of) reasonable stacks:

https://crash-stats.mozilla.com/report/index/e47b02da-92f0-4613-852a-cb55a0180820
https://crash-stats.mozilla.com/report/index/4c85d0e2-b044-4311-b14c-6ca350180820

But I can't tell what sort of SQL is being executed that's taking so long here.
Flags: needinfo?(nfroyd) → needinfo?(bugmail)
I wonder if this is somehow related to Sync? Bug 1483976 has a similar hang and I suspect bug 1483241 will too. Sadly, I don't think we can tell from the crash whether Sync is configured.

Comment 8

7 months ago
Top 50 Crashing Signatures. 7 days ago

Top Crashers for Firefox 64.0a1

4 	2.67% 	-0.18% 	AsyncShutdownTimeout | Places Connection shutdown | PlacesUtils read-only connection closing as part of Places shutdown 	111 	100 	6 	5 	93 	0 	2017-08-06 

Top Crashers for Firefox 63.0b
	
5 	1.46% 	0.5% 	AsyncShutdownTimeout | Places Connection shutdown | PlacesUtils read-only connection closing as part of Places shutdown	471 	440 	25 	6 	415 	0 	2017-08-06	

Top Crashers for Firefox 62.0.3

3 	2.58% 	-0.34% 	AsyncShutdownTimeout | Places Connection shutdown | PlacesUtils read-only connection closing as part of Places shutdown	3682 	3497 	123 	62 	2952 	0 	2017-08-06 

Top Crashers for Firefox 61.0.2

12 	1.08% 	0.22% 	AsyncShutdownTimeout | Places Connection shutdown | PlacesUtils read-only connection closing as part of Places shutdown	40 	33 	7 	0 	39 	0 	2017-08-06

Top Crashers for Firefox 60.0.2

12 	0.92% 	-0.49% 	AsyncShutdownTimeout | Places Connection shutdown | PlacesUtils read-only connection closing as part of Places shutdown	12 	12 	0 	0 	12 	0 	2017-08-06
	
Top Crashers for Firefox 60.2.2esr	
	
20 	0.47% 	0.01% 	AsyncShutdownTimeout | Places Connection shutdown | PlacesUtils read-only connection closing as part of Places shutdown	110 	105 	4 	1 	82 	0 	2017-08-06
Keywords: top50, topcrash
We should still keep an eye on this for 63. It was very high volume in 62 release.
I'll happily take a patch for this if one materializes, but I don't see much value in tracking this either.
Flags: needinfo?(bugmail)
Calling this stalled for now. It is still a top crash on release and beta.

Comment 12

4 months ago

I'm experiencing this bug about once per day so I can fill in some details for you.

The actual crash reported here happens only when you exit Firefox. But things go wrong long before that. The two symptoms of the issue are that Firefox uses 100% CPU (but never more) and your bookmarks become completely read-only. You can't add, modify, remove, or re-arrange them either with drag and drop or with the bookmarks editor. Other than this the browser operates completely normally.

When I run the places integrity test in about:support it says:

Unable to check favicons.sqlite integrity: Error: Could not open connection to /home/al/.mozilla/firefox/o65awu5u.default-1503600779742/favicons.sqlite: 2153971713

That is NS_ERROR_STORAGE_BUSY in case you are wondering.

After restarting Firefox all these problems go away, but they come back after about 24 hours.

In my case bookmark sync is enabled. In fact I only recently enabled it, and I only recently saw this start to happen. I have now disabled bookmark sync to see if it makes this problem go away.

(In reply to Alistair Buxton from comment #12)

The actual crash reported here happens only when you exit Firefox. But things go wrong long before that. The two symptoms of the issue are that Firefox uses 100% CPU (but never more) and your bookmarks become completely read-only. You can't add, modify, remove, or re-arrange them either with drag and drop or with the bookmarks editor. Other than this the browser operates completely normally.

I see a few possible reasons for this, that you could check:

  1. favicons.sqlite file is corrupt in some strange way. In this case the best path forward is to delete it and let Firefox generate a new one (you'll have to reaload pages to collect new favicons, sorry). After that, try running the Integrity check in about:support and check it reports things as sane.
  2. The filesystem where this file lives is not well supported by Sqlite. What is it? Is this profile on a network mounted fs?
  3. Some third party software keeps our databases open/locked, for some reason. If you have external app that may be running in background and access (for whatever reason) firefox profile, it may cause this. It's less likely on Linux than on other OS anyway.
Flags: needinfo?(a.j.buxton)

Comment 14

4 months ago
  1. After restarting Firefox the integrity test says the file is fine until the next time the bug happens.
  2. The filesystem is just a regular local Linux ext4 filesystem on Ubuntu.
  3. No third party software but I am using the Livemarks extension which gives the bookmark subsystem a good workout. This is probably making it happen faster for me than for other people, but it still takes about a day.

Since disabling bookmark sync two days ago I have not observed the problem happening again, but it is perhaps too early to tell yet.

Flags: needinfo?(a.j.buxton)

Comment 15

4 months ago

I also just ran PRAGMA integrity_check on the database and it found no errors. I'll retry this next time I can reproduce the error.

Are you using Nightly? Could you please check the value of the services.sync.engine.bookmarks.buffer pref in about:config?

Comment 17

4 months ago

I am using 64.0 and that key is set to false. I also noticed that services.sync.engine.bookmarks.validation.interval is set to 86400 - presumably seconds ie exactly 24 hours. Perhaps this goes some way to explaining frequency of the bug.

(In reply to Alistair Buxton from comment #17)

I am using 64.0 and that key is set to false. I also noticed that services.sync.engine.bookmarks.validation.interval is set to 86400 - presumably seconds ie exactly 24 hours. Perhaps this goes some way to explaining frequency of the bug.

FWIW, we chatted in #sync and determined that bookmark validation isn't running in that profile, so I think we can rule that out (but not necessarily rule out bookmark syncing in general)

This bug is causing Firefox 66.0.5 to crash on my Dell Inspiron 7558 several times a day. I've asked Mozilla Support about this on https://support.mozilla.org/en-US/questions/1259452

Flags: needinfo?(mak77)

Thanks for the report!
Based on the support thread, it seems to be related to very long Syncs, thus I'm forwarding to Lina to get a proper Sync log from you.

Did you try the suggestion to run Integrity Check that was posted in the support forum? Note that Refreshing Firefox doesn't run that, so it may still be relevant.

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