TL;DR:\u00a0 if you’re familiar with any Mozilla (C++ or JS) code that opens an async database connection, please go and check that it calls asyncClose() to close the connection;\u00a0 not doing so can lead to crashes and\/or memory leaks.<\/p>\n
Specifically, in Firefox 6, when such a connection is destroyed (because it’s explicitly deallocated or its refcount drops to zero in C++, or it’s garbage collected in JS) it’ll currently cause sporadic crashes in about:memory or telemetry code or Test Pilot code.\u00a0 This is because memory reporters end up pointing to connections that have been freed, and so when they are used they end up (innocently) accessing memory they shouldn’t.<\/p>\n
I’ve opened bug 662989<\/a> to avoid the crashes, but even once it’s implemented, I think that if you fail to call asyncClose() it will still cause a memory leak, because sqlite3_close() is never called on the connection and so SQLite won’t free up memory used by the connection.\u00a0 Also, connections that needlessly remain open can have active locks that can starve out other connections or cause extreme growth of the write-ahead-log.<\/p>\n As I write this, thanks to Marco Bonardo, I’m aware of three places in JS code that fail to call asyncClose() when they should:<\/p>\n These were found via a crude MXR<\/a> search.\u00a0 I haven’t looked for C++ code that makes this mistake.<\/p>\n If you only do synchronous transactions over your database connection, the connection will be cleaned up properly, even if you don’t call close(), when it is deallocated or garbage collected.\u00a0 However, it’s better to close the connection as soon as you can so that the resources (memory, locks) are freed immediately.<\/p>\n See this MDC page<\/a> for more details about database connections and the relevant APIs.\u00a0 It appears that these APIs are somewhat error-prone.\u00a0 As it happens, an NS_ENSURE_TRUE macro will fail when an async connection is destroyed without having been asyncClose’d first, and this causes a warning message to be printed to stderr.\u00a0 Unfortunately, stderr is spammed with all sorts of warnings (something that was discussed in the comments of a previous post<\/a> of mine), and so this warning gets lost among the noise.\u00a0 Addressing this problem is something I’ll write about shortly.<\/p>\n Thanks to Andrew Sutherland and Marco Bonardo for helping me greatly with the bugs mentioned above.\u00a0 Any errors in this post are mine!<\/p>\n\n