Assertion: SQLite: [p->inTrans->TRANS_NONE]




9 years ago
9 years ago


(Reporter: mak, Unassigned)


Dependency tree / graph

Firefox Tracking Flags

(Not tracked)




(2 attachments)



9 years ago
This happens in Places but i'm filing under storage since it's an sqlite assertion and is probably caused by concurrent sync and async queries

Replacing UNION ALL with UNION in mDBGetChildren query, that is executed by nsNavBookmarks::QueryFolderChildren solves the assertion, so i think there is a transaction that exists before the query runs, but is removed between the first and the second part of the UNION ALL. Not shure how that's possible though.

Here is the stack when i hit the assertion, i can usually reproduce running tests in toolkit/components/places/tests/bookmarks/ but there is also a Gentoo bug filed for a similar issue:
In the Gentoo case they were/are probably using system SQLite, but i'm on Windows and i reproduces with a completely clobber build (VS2008 + Windows7 sdk).

     [Frames below may be incorrect and/or missing, no symbols loaded for
>	xpc3250.dll!DEBUG_CheckWrapperThreadSafety(const XPCWrappedNative * wrapper=0x00d20000)  Line 3677 + 0x29 bytes	C++
     sqlite3.dll!sqlite3MemMalloc(int nByte=384)  Line 12540 + 0xd bytes    C
     sqlite3.dll!sqlite3Malloc(int n=0)  Line 15873 + 0xa bytes    C
     sqlite3.dll!sqlite3DbMallocRaw(sqlite3 * db=0x01df5dfc, int n=31416024) 
Line 16178 + 0x9 bytes    C
     sqlite3.dll!btreeCursor(Btree * p=0x016d4ea0, int iTable=2, int wrFlag=0,
KeyInfo * pKeyInfo=0x00000000, BtCursor * pCur=0x0204dd28)  Line 40843 + 0x20
bytes    C
     sqlite3.dll!sqlite3BtreeCursor(Btree * p=0x016d4ea0, int iTable=2, int
wrFlag=0, KeyInfo * pKeyInfo=0x00000000, BtCursor * pCur=0x0204dd28)  Line
40880 + 0x19 bytes    C
     sqlite3.dll!sqlite3VdbeExec(Vdbe * p=0x016b2830)  Line 54777 + 0x2a bytes 
     sqlite3.dll!sqlite3Step(Vdbe * p=0x016b2830)  Line 50423 + 0x9 bytes    C
     sqlite3.dll!sqlite3_step(sqlite3_stmt * pStmt=0x016b2830)  Line 50484 +
0x9 bytes    C
     storagecomps.dll!mozilla::storage::Statement::ExecuteStep(int *
_moreResults=0x0012ef04)  Line 713 + 0xc bytes    C++
     places.dll!nsNavBookmarks::QueryFolderChildren(__int64 aFolderId=3,
nsNavHistoryQueryOptions * aOptions=0x02046cf8,
nsCOMArray<nsNavHistoryResultNode> * aChildren=0x0204b470)  Line 2417 + 0x26
bytes    C++
     places.dll!nsNavHistoryFolderResultNode::FillChildren()  Line 3373 + 0x2c
bytes    C++
     places.dll!nsNavHistoryFolderResultNode::OpenContainer()  Line 3193 + 0x8
bytes    C++
aContainerOpen=1)  Line 550    C++
aContainerOpen=1)  Line 763 + 0x10 bytes    C++
     xpcom_core.dll!NS_InvokeByIndex_P(nsISupports * that=0x00000012, unsigned
int methodIndex=1, unsigned int paramCount=1241672, nsXPTCVariant *
params=0x0204ccd0)  Line 102    C++
     xpc3250.dll!XPCWrappedNative::CallMethod(XPCCallContext & ccx={...},
XPCWrappedNative::CallMode mode=CALL_SETTER)  Line 2710 + 0x21 bytes    C++
     xpc3250.dll!XPCWrappedNative::SetAttribute(XPCCallContext & ccx={...}) 
Line 2527 + 0xe bytes    C++
     xpc3250.dll!XPC_WN_GetterSetter(JSContext * cx=0x0164dcd8, JSObject *
obj=0x02011440, unsigned int argc=1, int * argv=0x0164f5f8, int *
vp=0x0012f51c)  Line 1776 + 0xc bytes    C++
     js3250.dll!js_Invoke(JSContext * cx=0x0164dcd8, unsigned int argc=1, int *
vp=0x0164f5f0, unsigned int flags=2)  Line 1363 + 0x1a bytes    C++
     js3250.dll!js_InternalInvoke(JSContext * cx=0x0164dcd8, JSObject *
obj=0x02011440, int fval=33625184, unsigned int flags=0, unsigned int argc=1,
int * argv=0x0012fcb4, int * rval=0x0012fcb4)  Line 1426 + 0x15 bytes    C++
     js3250.dll!js_InternalGetOrSet(JSContext * cx=0x0164dcd8, JSObject *
obj=0x02011440, int id=22162316, int fval=33625184, JSAccessMode
mode=JSACC_WRITE, unsigned int argc=1, int * argv=0x0012fcb4, int *
rval=0x0012fcb4)  Line 1462 + 0x1f bytes    C++
     js3250.dll!JSScopeProperty::set(JSContext * cx=0x0164dcd8, JSObject *
obj=0x02011440, int * vp=0x0012fcb4)  Line 810 + 0x23 bytes    C++
     js3250.dll!js_NativeSet(JSContext * cx=0x0164dcd8, JSObject *
obj=0x02011440, JSScopeProperty * sprop=0x0174b678, bool added=false, int *
vp=0x0012fcb4)  Line 4349 + 0x14 bytes    C++
     js3250.dll!js_SetPropertyHelper(JSContext * cx=0x0164dcd8, JSObject *
obj=0x02011440, int id=22162316, unsigned int defineHow=1, int * vp=0x0012fcb4)
 Line 4746 + 0x1a bytes    C++
     js3250.dll!js_Interpret(JSContext * cx=0x0164dcd8)  Line 1884 + 0x1f bytes
     js3250.dll!js_Execute(JSContext * cx=0x0164dcd8, JSObject *
chain=0x01cc2b60, JSScript * script=0x016650b8, JSStackFrame * down=0x00000000,
unsigned int flags=0, int * result=0x0012fe08)  Line 1598 + 0x9 bytes    C++
     js3250.dll!JS_EvaluateUCScriptForPrincipals(JSContext * cx=0x0164dcd8,
JSObject * obj=0x01cc2b60, JSPrincipals * principals=0x015e9e9c, const unsigned
short * chars=0x016681c8, unsigned int length=16, const char *
filename=0x0041864c, unsigned int lineno=1, int * rval=0x0012fe08)  Line 5056 +
0x19 bytes    C++
     js3250.dll!JS_EvaluateScriptForPrincipals(JSContext * cx=0x0164dcd8,
JSObject * obj=0x01cc2b60, JSPrincipals * principals=0x015e9e9c, const char *
bytes=0x00d2f01d, unsigned int nbytes=16, const char * filename=0x0041864c,
unsigned int lineno=1, int * rval=0x0012fe08)  Line 5020 + 0x25 bytes    C++
     xpcshell.exe!ProcessArgs(JSContext * cx=0x0164dcd8, JSObject *
obj=0x01cc2b60, char * * argv=0x00d2ed2c, int argc=14)  Line 1193 + 0x3d bytes 
     xpcshell.exe!main(int argc=14, char * * argv=0x00d2ed2c, char * *
envp=0x00d24038)  Line 1879 + 0x15 bytes    C++
     xpcshell.exe!__tmainCRTStartup()  Line 586 + 0x19 bytes    C
     xpcshell.exe!mainCRTStartup()  Line 403    C
     js3250.dll!NativeToValueBase<FailDoubleOOMHandler>(JSContext *
cx=0xcccccccc, int & v=, JSTraceType_ type='Ì', double * slot=0xcccccccc)  Line
2690 + 0x7 bytes    C++


9 years ago
Summary: Sqlite assertion p->inTrans->TRANS_NONE → Assertion: SQLite: [p->inTrans->TRANS_NONE]
Created attachment 406375 [details]
backtrace of assertion-failure on Linux (at Firefox startup)

Currently, I hit this assertion (and subsequently abort) at startup-time, whenever I run an up-to-date mozilla-central debug build on my personal profile.  This happens before any Firefox windows appear.

Attaching backtrace.
OS: Windows Vista → All
Hardware: x86 → All

Comment 2

9 years ago
i just tried to apply sqlite 3.6.19 to my tree, and it did not solve this.

Comment 3

9 years ago
a places test that can reproduce this is test_429505_remove_shortcuts.js

Comment 4

9 years ago
Created attachment 406433 [details] [diff] [review]

this solves the assertion.

what looks like is happening is that an async stmt creates an immediate transaction, first part of mDBGetChildren runs, then the async stmt ends and clear the transaction, and second part of mDBGetChildren runs, but while it started in a transaction it ends out of it.

I don't know if this hacky workaround can also solve the crash in bug 520541, could be interesting to know though.

Comment 5

9 years ago
Thanks for the clues.  We now have a reproducible test case in SQLite.
See for details.  We will get
this patched for you as soon as we can.

Comment 6

9 years ago
thank you, i really appreciate that :)
test_bookmarks.js is failing consistently with this error on Linux debug unittests.
Blocks: 523385

Comment 8

9 years ago
if we don't have a clear timeline for sqlite 3.6.20 we can eventually land my workaround in the meantime, and back it out as soon as we update sqlite.

Comment 9

9 years ago
or backout sqlite 3.6.18 and go back to 3.6.16, i think shawn was thinking to that.

Comment 10

9 years ago
SQLite version 3.6.20 will be early-to-mid November.  But we are happy to push out a patch release ( containing only the bug fixes that impact FF.  We can do that in about a day.  All you have to do is ask and it will be done.
This is causing test_bookmarks.js to fail on debug unittests.

Comment 12

9 years ago
If Shawn is ok with that, i think there's no need to rush an sqlite version from sqlite team, we should instead just backout 3.6.18 on central and wait for .20, we don't rely on any new feature that was not present in 3.6.16.

Comment 13

9 years ago
Another option is to simply use intermediate SQLite check-ins.

Historically, FF has only used official SQLite releases.  This was a good policy because it made it very clear exactly which SQLite version was being used within FF.  But SQLite has now shifted configuration management from CVS to Fossil, and every check-in now comes with identifying information that can trace it back to its original source.  You can use the SQLITE_SOURCE_ID #define or the sqlite3_sourceid() C/C++ interface or the sqlite_source_id() SQL function to access this information.  These will give you the date and time of the check-in and the SHA1 hash of the entire check-in.  This gives you complete traceability of the specific check-in of SQLite that you are using and largely erases the need to stick to an "official release".

We can give you guidance about which SQLite check-ins are suitable for use in Mozilla Central and which you should avoid, if you want to go with this approach.
The problem with that approach is that it will break linux distros that ship with system SQLite.

Comment 15

9 years ago
I've argued that such linux distros are already broken, though I've found that argument doesn't cut much hay with the distros themselves, so let's move on....

Maybe you want to put a intermediate check-in of SQLite in nightly builds, then settle on an official SQLite release version when you get close to a FF release?  That gives you the opportunity to run with an SQLite that contains all of the latest bug fixes and thereby avoid unsightly work-arounds in the FF code.
We should just wait.  I don't actually have time to get a new version landing for a for weeks anyway, so you might have released by then!
I'll backout bug 519270 once the tree reopens today.


9 years ago
Depends on: 519270
Fixed by backout of bug 519270.
Last Resolved: 9 years ago
Resolution: --- → FIXED


9 years ago
Blocks: 519270
No longer depends on: 519270
You need to log in before you can comment on or make changes to this bug.