1387897 - Crash in sqlite3Malloc

Status: RESOLVED WORKSFORME

(Core :: SQLite and Embedded Database Bindings, defect, P3)

Description

[baffclan]

This bug was filed from the Socorro interface and is 
report bp-4a611833-ebc2-48da-a83c-274480170806.
=============================================================

Crash when open a new tab after update.


Crashing Thread (56), Name: mozStorage #3
Frame 	Module 	Signature 	Source
0 	nss3.dll 	sqlite3Malloc 	db/sqlite3/src/sqlite3.c:24492
1 		@0x1f 	
2 		@0x1add628550f 	
3 	nss3.dll 	sqlite3_free 	db/sqlite3/src/sqlite3.c:24675
4 		@0x18e045f57f 	
5 	xul.dll 	PrintfAppend_nsACString::append(char const*, unsigned __int64) 	xpcom/string/nsTSubstring.cpp:986
6 	mozglue.dll 	mozilla::PrintfTarget::vprint(char const*, char*) 	mozglue/misc/Printf.cpp:881
7 	mozglue.dll 	mozilla::TimeStamp::Now(bool) 	mozglue/misc/TimeStamp_windows.cpp:553
8 	xul.dll 	mozilla::storage::Connection::stepStatement(sqlite3*, sqlite3_stmt*) 	storage/mozStorageConnection.cpp:1129
9 	xul.dll 	mozilla::storage::AsyncExecuteStatements::executeStatement(sqlite3_stmt*) 	storage/mozStorageAsyncStatementExecution.cpp:235
10 	xul.dll 	mozilla::storage::AsyncExecuteStatements::executeAndProcessStatement(sqlite3_stmt*, bool) 	storage/mozStorageAsyncStatementExecution.cpp:179
11 	xul.dll 	mozilla::storage::AsyncExecuteStatements::Run() 	storage/mozStorageAsyncStatementExecution.cpp:563
12 	xul.dll 	nsThread::ProcessNextEvent(bool, bool*) 	xpcom/threads/nsThread.cpp:1446
13 	xul.dll 	NS_ProcessNextEvent(nsIThread*, bool) 	xpcom/threads/nsThreadUtils.cpp:480
14 	xul.dll 	mozilla::ipc::MessagePumpForNonMainThreads::Run(base::MessagePump::Delegate*) 	ipc/glue/MessagePump.cpp:369
15 	xul.dll 	MessageLoop::RunHandler() 	ipc/chromium/src/base/message_loop.cc:319
16 	xul.dll 	MessageLoop::Run() 	ipc/chromium/src/base/message_loop.cc:299
17 	xul.dll 	nsThread::ThreadFunc(void*) 	xpcom/threads/nsThread.cpp:506
18 	nss3.dll 	PR_NativeRunThread 	nsprpub/pr/src/threads/combined/pruthr.c:397
19 	nss3.dll 	pr_root 	nsprpub/pr/src/md/windows/w95thred.c:95
20 	ucrtbase.dll 	o__strtoui64 	
21 	kernel32.dll 	BaseThreadInitThunk 	
22 	ntdll.dll 	RtlUserThreadStart 	



Application Basics: 
Name: Firefox
Version: 57.0a1
Build ID: 20170806100257
Update Channel: nightly
User Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:57.0) Gecko/20100101 Firefox/57.0
OS: Windows_NT 10.0

Comment 1

[:Gijs (away/busy until Mar 10)]

Is this 100% reproducible for you? If so, can you try finding when this regressed / what broke this? ( https://mozilla.github.io/mozregression/ )

Comment 2

[baffclan]

(In reply to :Gijs from comment #1)
> Is this 100% reproducible for you? If so, can you try finding when this
> regressed / what broke this? ( https://mozilla.github.io/mozregression/ )

No, there is no reproducibility.
This crash has occurred for the first time.

Comment 3

[Andrew Sutherland [:asuth] (he/him)]

The stack looks fairly trashed, which seems corroborated by the crash report's raw dump showing frame trusts of: [context, cfi, scan, frame_pointer, scan, cfi, cfi, cfi,...].

It looks likely we're seeing a mash-up of the following stack trees:
- mozilla::storage::Connection::stepStatement
  - mozilla::TimeStamp::Now
  - Telemetry::RecordSlowSQLStatement
    - nsAutoCString::AppendPrintf
      - mozilla::PrintfTarget::vprint
        - mozilla::PrintfTarget::emit (optimized away?)
          - PrintfAppend_nsACString::append (impl of pure virtual mozilla::PrintfTarget::append)
  - sqlite3_step (not observed, but likely necessary for sqlite3_free and sqlite3Malloc)
    - ...
      - sqlite3_free
    - ...
      - sqlite3Malloc

The Telemetry::RecordSlowSQLStatement frame has at most one live nsAutoCString on the stack with kDefaultStorageSize=64, although if the compiler wasn't optimizing particularly hard, the other 2 mutually exclusive nsAutoCString's might have stack allocated for them them.


In general, I think we'd expect there to potentially be a number of differing crash signatures.  If we search for Connection::stepStatement on the "proto signature" (which seems to be the only way to search for things further up the stack?), then we do seem to find some other crashers that may or may not be related.  Based on a quick random sampling, there's no obvious smoking gun.  General memory-misuse shenanigans like use-after-free seem most likely since stack overwrites necessarily manifest during stack popping in a somewhat incriminating way.  And the most suspicious calls like TelemetryImpl::SanitizeSQL and Place's FixupURLFunction seem to be doing safe nsString-based manipulation and should be called at a high enough frequency to be more present in our crash reports if they were the actual causes.

So in summary, we should keep an eye on this one, but I think this is likely us getting burnt by a use-after-free from some other code.

1: https://crash-stats.mozilla.com/search/?proto_signature=~mozilla%3A%3Astorage%3A%3AAsyncExecuteStatements%3A%3AexecuteStatement&product=Firefox&date=%3E%3D2017-07-08T15%3A30%3A50.000Z&date=%3C2017-08-08T15%3A30%3A50.000Z&_sort=-version&_sort=-date&_facets=signature&_columns=date&_columns=signature&_columns=product&_columns=version&_columns=build_id&_columns=platform#crash-reports

Comment 4

[BugBot [:suhaib / :marco/ :calixte]]

Since the crash volume is low (less than 5 per week), the severity is downgraded to S3. Feel free to change it back if you think the bug is still critical.

For more information, please visit auto_nag documentation.

Comment 5

[BugBot [:suhaib / :marco/ :calixte]]

Closing because no crashes reported for 12 weeks.