Closed Bug 760243 Opened 12 years ago Closed 12 years ago

Lightning enabled in TB trunk - Assertion failure: !connections[i]->ConnectionReady(), mozStorageService.cpp:852

Categories

(Calendar :: Internal Components, defect)

Lightning 1.7
defect
Not set
critical

Tracking

(Not tracked)

RESOLVED FIXED

People

(Reporter: aceman, Assigned: ssitter)

References

Details

Attachments

(8 files)

+++ This bug was initially created as a clone of Bug #758688 +++

After bug 758688 got fixed I still see a similar crash when the Lightning addon is enabled in TB trunk.
This is the end of the console output:

###!!! ASSERTION: Oops!  You're asking for a weak reference to an object that doesn't support that.: 'factoryPtr', file /var/SSD/TB-hg/tbird-bin/mozilla/xpcom/build/nsWeakReference.cpp, line 77
************************************************************
* Call to xpconnect wrapped JSObject produced this error:  *
[Exception... "Component returned failure code: 0x80004005 (NS_ERROR_FAILURE) [nsIObserverService.removeObserver]"  nsresult: "0x80004005 (NS_ERROR_FAILURE)"  location: "JS frame :: resource://calendar/modules/calUtils.jsm -> file:///var/SSD/TB-hg/tbird-bin/mozilla/dist/bin/extensions/%7Be2fda1a4-762b-4020-b5ad-a41df1933103%7D/calendar-js/calCalendarManager.js :: ccm_shutdown :: line 165"  data: no]
************************************************************
************************************************************
* Call to xpconnect wrapped JSObject produced this error:  *
[Exception... "Component returned failure code: 0x80004005 (NS_ERROR_FAILURE) [nsIObserverService.removeObserver]"  nsresult: "0x80004005 (NS_ERROR_FAILURE)"  location: "JS frame :: resource://calendar/modules/calUtils.jsm -> file:///var/SSD/TB-hg/tbird-bin/mozilla/dist/bin/extensions/%7Be2fda1a4-762b-4020-b5ad-a41df1933103%7D/calendar-js/calCalendarManager.js :: ccm_shutdown :: line 165"  data: no]
************************************************************
************************************************************
* Call to xpconnect wrapped JSObject produced this error:  *
[Exception... "Component returned failure code: 0x80004005 (NS_ERROR_FAILURE) [nsIObserverService.removeObserver]"  nsresult: "0x80004005 (NS_ERROR_FAILURE)"  location: "JS frame :: file:///var/SSD/TB-hg/tbird-bin/mozilla/dist/bin/components/steelApplication.js :: app_observe :: line 622"  data: no]
************************************************************
WARNING: nsExceptionService ignoring thread destruction after shutdown: file /var/SSD/TB-hg/mozilla/xpcom/base/nsExceptionService.cpp, line 166
Assertion failure: !connections[i]->ConnectionReady(), at /var/SSD/TB-hg/mozilla/storage/src/mozStorageService.cpp:852

Program ./thunderbird (pid = 20005) received signal 6.
Stack:
__kernel_rt_sigreturn+0x00000000 [linux-gate.so.1 +0x0000040C]
UNKNOWN [/var/SSD/TB-hg/tbird-bin/mozilla/dist/bin/libxul.so +0x0131D604]
UNKNOWN [/var/SSD/TB-hg/tbird-bin/mozilla/dist/bin/libxul.so +0x0131DEEB]
UNKNOWN [/var/SSD/TB-hg/tbird-bin/mozilla/dist/bin/libxul.so +0x0130E0D2]
UNKNOWN [/var/SSD/TB-hg/tbird-bin/mozilla/dist/bin/libxul.so +0x00226CAF]
UNKNOWN [/var/SSD/TB-hg/tbird-bin/mozilla/dist/bin/libxul.so +0x0022E2CB]
XRE_main+0x000000A7 [/var/SSD/TB-hg/tbird-bin/mozilla/dist/bin/libxul.so +0x0022E4B1]
UNKNOWN [./thunderbird +0x00001E32]
Sleeping for 300 seconds.
I applied patch https://bugzilla.mozilla.org/attachment.cgi?id=627338 and I get output like this:

0 XPIDB_shutdown() ["resource://gre/modules/XPIProvider.jsm":4635]
    this = [object Object]
1 XPI_shutdown() ["resource://gre/modules/XPIProvider.jsm":1719]
    this = [object Object]
2 <TOP LEVEL> ["<unknown>":0]
    <failed to get 'this' value>
3 callProvider() ["resource://gre/modules/AddonManager.jsm":108]
    this = undefined
4 anonymous() ["resource://gre/modules/AddonManager.jsm":644]
    this = undefined
5 AMI_shutdown() ["resource://gre/modules/AddonManager.jsm":643]
    this = [object Object]
6 AMP_shutdown() ["resource://gre/modules/AddonManager.jsm":1892]
    this = [object Object]
7 <TOP LEVEL> ["<unknown>":0]
    <failed to get 'this' value>
8 AMC_observe() ["file:///var/SSD/TB-hg/tbird-bin/mozilla/dist/bin/components/addonManager.js":62]
    this = [object Object]
9 <TOP LEVEL> ["<unknown>":0]
    <failed to get 'this' value>

Rafael, what exactly should I look for?
Summary: Thunderbird Bloat & Mozmill tests - Assertion failure: !connections[i]->ConnectionReady(), mozStorageService.cpp:852 → Lightning enabled in TB trunk - Assertion failure: !connections[i]->ConnectionReady(), mozStorageService.cpp:852
With the patch thunderbird will print a backtrace every time a connection is open and closed. An open will be marked with

ESPINDOLA: Connection::Connection

and a close will be marked with

ESPINDOLA: Close

or

ESPINDOLA: AsyncClose

There should be a connection that is being opened but not closed and a backtrace showing where it was open.
Attached file log with DB tracing ā€”
OK, here is the log. I think the connections 2,3 and 6 are not closed. However I do not know which DBs that are, because I don't know which debug block belongs to which connection. It looks like the block is just before the line with "Connection::connection X', but there is nothing before Connection 1 so I am not sure.
Attachment #629466 - Flags: feedback?(respindola)
The backtraces of the connections that are not being closed are

0 _initDB() ["file:///var/SSD/TB-hg/tbird-bin/mozilla/dist/bin/extensions/%7Be2fda1a4-762b-4020-b5ad-a41df1933103%7D/components/calTimezoneService.js":166]
    this = [object Object]
1 tryTzUri() ["file:///var/SSD/TB-hg/tbird-bin/mozilla/dist/bin/extensions/%7Be2fda1a4-762b-4020-b5ad-a41df1933103%7D/components/calTimezoneService.js":221]
    this = [object BackstagePass @ 0xaf144040 (native @ 0xb2cff124)]
2 calTimezoneService_initialize([xpconnect wrapped calIGenericOperationListener @ 0xaf19de00 (native @ 0xaf3a0ab0)]) ["file:///var/SSD/TB-hg/tbird-bin/mozilla/dist/bin/extensions/%7Be2fda1a4-762b-4020-b5ad-a41df1933103%7D/components/calTimezoneService.js":228]
    this = [object Object]
3 anonymous() ["file:///var/SSD/TB-hg/tbird-bin/mozilla/dist/bin/extensions/%7Be2fda1a4-762b-4020-b5ad-a41df1933103%7D/components/calTimezoneService.js":157]
    this = [object Object]
4 startup() ["file:///var/SSD/TB-hg/tbird-bin/mozilla/dist/bin/extensions/%7Be2fda1a4-762b-4020-b5ad-a41df1933103%7D/components/calTimezoneService.js":118]
    this = [object Object]
5 <TOP LEVEL> ["<unknown>":0]
    <failed to get 'this' value>
6 callOrderedServices("startup", [xpconnect wrapped (nsISupports, calICalendarManager, calIStartupService, nsIObserver, nsIClassInfo) @ 0xaf19d8c0 (native @ 0xaf3a0a00)],[object Object]) ["resource://calendar/modules/calUtils.jsm -> file:///var/SSD/TB-hg/tbird-bin/mozilla/dist/bin/extensions/%7Be2fda1a4-762b-4020-b5ad-a41df1933103%7D/calendar-js/calStartupService.js":20]
    this = [object BackstagePass @ 0xafabb040 (native @ 0xb2cff124)]
7 observe() ["resource://calendar/modules/calUtils.jsm -> file:///var/SSD/TB-hg/tbird-bin/mozilla/dist/bin/extensions/%7Be2fda1a4-762b-4020-b5ad-a41df1933103%7D/calendar-js/calStartupService.js":103]
    this = [object Object]
8 <TOP LEVEL> ["<unknown>":0]
    <failed to get 'this' value>


-----------------------------------

0 calmgr_checkAndMigrateDB() ["resource://calendar/modules/calUtils.jsm -> file:///var/SSD/TB-hg/tbird-bin/mozilla/dist/bin/extensions/%7Be2fda1a4-762b-4020-b5ad-a41df1933103%7D/calendar-js/calCalendarManager.js":435]
    this = [object Object]
1 ccm_startup() ["resource://calendar/modules/calUtils.jsm -> file:///var/SSD/TB-hg/tbird-bin/mozilla/dist/bin/extensions/%7Be2fda1a4-762b-4020-b5ad-a41df1933103%7D/calendar-js/calCalendarManager.js":135]
    this = [object Object]
2 callOrderedServices("startup", [object Object]) ["resource://calendar/modules/calUtils.jsm -> file:///var/SSD/TB-hg/tbird-bin/mozilla/dist/bin/extensions/%7Be2fda1a4-762b-4020-b5ad-a41df1933103%7D/calendar-js/calStartupService.js":20]
    this = [object BackstagePass @ 0xafabb040 (native @ 0xb2cff124)]
3 anonymous() ["resource://calendar/modules/calUtils.jsm -> file:///var/SSD/TB-hg/tbird-bin/mozilla/dist/bin/extensions/%7Be2fda1a4-762b-4020-b5ad-a41df1933103%7D/calendar-js/calStartupService.js":21]
    this = [object Object]
4 <TOP LEVEL> ["<unknown>":0]
    <failed to get 'this' value>
5 calTimezoneService_initialize([xpconnect wrapped calIGenericOperationListener @ 0xaf19de00 (native @ 0xaf3a0ab0)]) ["file:///var/SSD/TB-hg/tbird-bin/mozilla/dist/bin/extensions/%7Be2fda1a4-762b-4020-b5ad-a41df1933103%7D/components/calTimezoneService.js":252]
    this = [object Object]
6 anonymous() ["file:///var/SSD/TB-hg/tbird-bin/mozilla/dist/bin/extensions/%7Be2fda1a4-762b-4020-b5ad-a41df1933103%7D/components/calTimezoneService.js":157]
    this = [object Object]
7 startup() ["file:///var/SSD/TB-hg/tbird-bin/mozilla/dist/bin/extensions/%7Be2fda1a4-762b-4020-b5ad-a41df1933103%7D/components/calTimezoneService.js":118]
    this = [object Object]
8 <TOP LEVEL> ["<unknown>":0]
    <failed to get 'this' value>
9 callOrderedServices("startup", [object Object]) ["resource://calendar/modules/calUtils.jsm -> file:///var/SSD/TB-hg/tbird-bin/mozilla/dist/bin/extensions/%7Be2fda1a4-762b-4020-b5ad-a41df1933103%7D/calendar-js/calStartupService.js":20]
    this = [object BackstagePass @ 0xafabb040 (native @ 0xb2cff124)]
10 observe() ["resource://calendar/modules/calUtils.jsm -> file:///var/SSD/TB-hg/tbird-bin/mozilla/dist/bin/extensions/%7Be2fda1a4-762b-4020-b5ad-a41df1933103%7D/calendar-js/calStartupService.js":103]
    this = [object Object]
11 <TOP LEVEL> ["<unknown>":0]
    <failed to get 'this' value>

-----------------------------------------

0 cSC_prepareInitDB() ["file:///var/SSD/TB-hg/tbird-bin/mozilla/dist/bin/extensions/%7Be2fda1a4-762b-4020-b5ad-a41df1933103%7D/components/calStorageCalendar.js":363]
    this = [object Object]
1 anonymous() ["file:///var/SSD/TB-hg/tbird-bin/mozilla/dist/bin/extensions/%7Be2fda1a4-762b-4020-b5ad-a41df1933103%7D/components/calStorageCalendar.js":174]
    this = [object Object]
2 <TOP LEVEL> ["<unknown>":0]
    <failed to get 'this' value>
3 cmgr_assureCache() ["resource://calendar/modules/calUtils.jsm -> file:///var/SSD/TB-hg/tbird-bin/mozilla/dist/bin/extensions/%7Be2fda1a4-762b-4020-b5ad-a41df1933103%7D/calendar-js/calCalendarManager.js":797]
    this = [object Object]
4 cmgr_getCalendars() ["resource://calendar/modules/calUtils.jsm -> file:///var/SSD/TB-hg/tbird-bin/mozilla/dist/bin/extensions/%7Be2fda1a4-762b-4020-b5ad-a41df1933103%7D/calendar-js/calCalendarManager.js":762]
    this = [object Object]
5 <TOP LEVEL> ["<unknown>":0]
    <failed to get 'this' value>
6 anonymous() ["file:///var/SSD/TB-hg/tbird-bin/mozilla/dist/bin/extensions/%7Be2fda1a4-762b-4020-b5ad-a41df1933103%7D/components/calCompositeCalendar.js":160]
    this = [object Object]
7 <TOP LEVEL> ["<unknown>":0]
    <failed to get 'this' value>
8 getCompositeCalendar() ["chrome://calendar/content/calUtils.js":2033]
    this = [object ChromeWindow @ 0xaeaab140 (native @ 0xb2c08c0c)]
9 () ["chrome://calendar/content/calendar-task-tree.xml":130]
    this = [object XULElement @ 0xaad40800 (native @ 0xab94a1a0)]

I will try to take a look once I find out how to build Lightning
Thanks for taking a look. Its true we don't close the connections explicitly, I believe we don't even finalize our statements! We have a helper function in calUtils.js (or calUtils.jsm) that sets up a shutdown observer, maybe its time to use that helper.

Building Lightning basically means building Thunderbird with ac_add_options --enable-calendar. See https://developer.mozilla.org/en/Simple_Thunderbird_build#Building_Thunderbird_and_Lightning for details.
Assignee: nobody → respindola
Status: NEW → ASSIGNED
Attachment #629863 - Flags: review?(philipp)
thunderbird closes correctly with this one.
Attachment #629873 - Flags: review?(philipp)
Comment on attachment 629863 [details] [diff] [review]
Close one of the connections.

Review of attachment 629863 [details] [diff] [review]:
-----------------------------------------------------------------

I'm going to set r- on this patch for lack of alternatives. It really depends on my comment below:

::: calendar/base/src/calTimezoneService.js
@@ +357,5 @@
>              // default timezone getter set up the correct timezone again.
>              this.mDefaultTimezone = null;
>          }
> +        if (aTopic == "profile-before-change")
> +            this.shutdown();

Is the timezone service not shut down? It should be shut down by the startup service, here:

http://mxr.mozilla.org/comm-central/source/calendar/base/src/calStartupService.js#106

If it is shut down, please remove the observer here (in that case r=philipp with observer removed).

If not, please fix the startup service to properly shutdown its services (in that case, r- for a new patch)
Attachment #629863 - Flags: review?(philipp) → review-
Comment on attachment 629866 [details] [diff] [review]
[checked in] close another one.

r=philipp
Attachment #629866 - Flags: review?(philipp) → review+
Comment on attachment 629873 [details] [diff] [review]
[checked in] "last" missing db

Review of attachment 629873 [details] [diff] [review]:
-----------------------------------------------------------------

::: calendar/providers/storage/calStorageCalendar.js
@@ +360,5 @@
>              // New style uri, no need for migration here
>              let localDB = cal.getCalendarDirectory();
>              localDB.append("local.sqlite");
>              localDB = Services.storage.openDatabase(localDB);
> +            Services.obs.removeObserver(this, "profile-before-change");

I'd prefer keeping the close code as close as possible, you could do it as follows:

cal.addObserver((function() this.mDB.close()).bind(this), "profile-before-change", true);

See this function: http://mxr.mozilla.org/comm-central/source/calendar/base/modules/calUtils.jsm#525

r=philipp with that changed and tested.
Attachment #629873 - Flags: review?(philipp) → review+
Attached patch [checked in] refactoring ā€” ā€” Splinter Review
Sorry, I only noticed your comment after pushing the original patch. The attached one is just the refactoring.
Attachment #630627 - Flags: review?(philipp)
OS: Linux → All
Version: Trunk → Lightning 1.7
Comment on attachment 630627 [details] [diff] [review]
[checked in] refactoring


>             localDB.append("local.sqlite");
>             localDB = Services.storage.openDatabase(localDB);
>-            Services.obs.removeObserver(this, "profile-before-change");
>+            cal.addObserver((function() this.mDB.close()).bind(this),
>+                            "profile-before-change", true);
> 
>             this.mDB = localDB;

Hmm could you put the addObserver calll after this.mDB = localDB? It will probably work due to late evaluation of this.mDB, but it looks wrong.

alternatively:

cal.addObserver(function() localDB.close(), "profile-before-change", true);


r=philipp with that change.
Attachment #630627 - Flags: review?(philipp) → review+
Is there anything to do here?
It seems the patches have landed, I'll test the trunk soon.
Comment on attachment 629866 [details] [diff] [review]
[checked in] close another one.

check in to https://hg.mozilla.org/comm-central/rev/f6ebae91f995
Attachment #629866 - Attachment description: close another one. → [checked in] close another one.
Comment on attachment 629873 [details] [diff] [review]
[checked in] "last" missing db

checked in to https://hg.mozilla.org/comm-central/rev/0a0d5257d2ec
Attachment #629873 - Attachment description: "last" missing db → [checked in] "last" missing db
Comment on attachment 630627 [details] [diff] [review]
[checked in] refactoring

checked in to https://hg.mozilla.org/comm-central/rev/686474e9b65d

this.mDB.close() was changed to localDB.close(). But is the locally scoped variable |localDB| still available during the later shutdown procedure?
Attachment #630627 - Attachment description: refactoring → [checked in] refactoring
Attachment #629466 - Flags: feedback?(respindola)
Target Milestone: --- → 1.8
Current trunk still hangs, so there really is something missing.
(In reply to :aceman from comment #22)
> Current trunk still hangs, so there really is something missing.

The patch with a review-.

I was not able to figure out why the timezone service is not shutdown. Philipp, were you able to reproduce the problem with a debug build?
(In reply to Stefan Sitter from comment #21)
> Comment on attachment 630627 [details] [diff] [review]
> [checked in] refactoring
> 
> checked in to https://hg.mozilla.org/comm-central/rev/686474e9b65d
> 
> this.mDB.close() was changed to localDB.close(). But is the locally scoped
> variable |localDB| still available during the later shutdown procedure?

The closure will keep the localDB variable alive so we are fine as long as it is not set to null explicitly.

(In reply to Rafael Ɓvila de Espƭndola (:espindola) from comment #23)
> (In reply to :aceman from comment #22)
> > Current trunk still hangs, so there really is something missing.
> 
> The patch with a review-.
> 
> I was not able to figure out why the timezone service is not shutdown.
> Philipp, were you able to reproduce the problem with a debug build?

I haven't had a chance to build one, just got a new harddrive and still migrating. Since without a debug build it works fine (with the slight changes we did in IRC), that could be a start, otherwise I'll have to look into it in the coming week.
Attached patch debug patch ā€” ā€” Splinter Review
I have to go work on another bug, so I am attaching what I have found so far in case someone else can take a look.

The attached patch adds a bunch of dump calls to try to find out what the regular shutdown process is not working. The failure is coming from XPC_WN_CallMethod. Setting a breakpoint in

    XPCCallContext ccx(JS_CALLER, cx, obj, funobj, JSID_VOID, argc, JS_ARGV(cx, vp), vp);
    XPCWrappedNative* wrapper = ccx.GetWrapper(); // HERE

will show that ccx.mWrapper is null in the case that fails. I still have to debug why.
Sorry, given that the problem is in the shutdown process and not in the changes I made to sql connections, I have to unassign myself as I will not have time to work on this any time soon.
Assignee: respindola → nobody
CalendarManager: Fix shutdown() being called twice, once incorrectly from observe() and once via calIStartupService. This caused crash during application shutdown resulting in shutdown() of TimezoneService not being called.

TimezoneService: Finalize statement before closing the database to fix error "ASSERTION: sqlite3_close failed. There are probably outstanding statements that are listed above!".

StorageProvider: There are 4 possibilities to open the database, ensure that database will be closed in any case. Finalize statements before closing the database to fix assertion error mentioned above.

With this patch applied the Debug build shutdowns correctly and doesn't crash during shutdown anymore.
Assignee: nobody → ssitter
Attachment #664807 - Flags: review?(philipp)
Attachment #664807 - Flags: feedback?(respindola)
Cool, maybe I'll be able to build calendar again :)
Comment on attachment 664807 [details] [diff] [review]
[checked in] finalize statements and close databases

Review of attachment 664807 [details] [diff] [review]:
-----------------------------------------------------------------

Looks good to me, very good catch! I hope this fixes our shutdown crash issues.

::: calendar/base/src/calTimezoneService.js
@@ +121,5 @@
>      shutdown: function shutdown(aCompleteListener) {
>          Services.prefs.removeObserver("calendar.timezone.local", this);
>  
> +        if (this.mSelectByTzid) { this.mSelectByTzid.finalize(); }
> +        if (this.mDb) { this.mDb.close(); this.mDb = null; }

Maybe we should keep this in a try/catch block, since not calling the onResult listener will mean the following services won't be shut down.
Attachment #664807 - Flags: review?(philipp) → review+
Pushed to https://hg.mozilla.org/comm-central/rev/55fbdfdedfc1 after adding back the try/catch block.
Target Milestone: 1.8 → 2.0
Attachment #664807 - Flags: feedback?(respindola)
I tested a lot with the patch and every time Thunderbird shutdown correct. Today I rebuild and now I get the following shutdown errors after adding/removing events:

> WARNING: NS_ENSURE_TRUE(asyncCloseWasCalled) failed: file .../src/mozilla/storage/src/mozStorageConnection.cpp, line 890
> ************************************************************
> * Call to xpconnect wrapped JSObject produced this error:  *
> [Exception... "Component returned failure code: 0x8000ffff (NS_ERROR_UNEXPECTED) [mozIStorageConnection.close]"  nsresult: "0x8000ffff (NS_ERROR_UNEXPECTED)"  location: "JS frame :: .../components/calStorageCalendar.js :: cSC_shutdownDB :: line 1489"  data: no]
> ************************************************************
> WARNING: NS_ENSURE_TRUE(asyncCloseWasCalled) failed: file .../src/mozilla/storage/src/mozStorageConnection.cpp, line 890
> ************************************************************
> * Call to xpconnect wrapped JSObject produced this error:  *
> [Exception... "Component returned failure code: 0x8000ffff (NS_ERROR_UNEXPECTED) [mozIStorageConnection.close]"  nsresult: "0x8000ffff (NS_ERROR_UNEXPECTED)"  location: "JS frame :: .../calendar-js/calDeletedItems.js :: shutdown :: line 150"  data: no]
> ************************************************************
> Assertion failure: !connections[i]->ConnectionReady(), at .../src/mozilla/storage/src/mozStorageService.cpp:837
OK, I hope I got it this time. Instead of close() use asyncClose(), add try/catch/logging block around the close, and fix some other small issue in shutdown.
Attachment #665578 - Flags: review?(philipp)
Attachment #664807 - Attachment description: finalize statements and close databases → [checked in] finalize statements and close databases
Another question: in calDeletedItems.js we work on database file in the users profile. Should the shutdown happen on "profile-before-change" instead of "xpcom-shutdown" as it is done now?
Comment on attachment 665578 [details] [diff] [review]
[checked in] use asyncClose() and add try/catch block

r=philipp, good catch on the getCalendarManager() function!
Attachment #665578 - Flags: review?(philipp) → review+
Comment on attachment 665578 [details] [diff] [review]
[checked in] use asyncClose() and add try/catch block

Pushed to https://hg.mozilla.org/comm-central/rev/b79fb7f5ae12
Attachment #665578 - Attachment description: use asyncClose() and add try/catch block → [checked in] use asyncClose() and add try/catch block
aceman, I think problem should be fixed now. Could you retest and validate if all problems are gone if time permits?
Yes I can.
It seems to work fine now, I can run with TB enabled in debug build and it does not hang/crash at shutdown.

Is there anything still open here?
I mean calendar enabled :)
Status: ASSIGNED → RESOLVED
Closed: 12 years ago
Resolution: --- → FIXED
Whiteboard: [leave open]
Comment on attachment 664807 [details] [diff] [review]
[checked in] finalize statements and close databases

Parts of the patches landed for 1.8. I'd like to take the remaining patches for 1.9 because it seems to be a long running release.
Attachment #664807 - Flags: approval-calendar-aurora?
Attachment #665578 - Flags: approval-calendar-aurora?
Attachment #664807 - Flags: approval-calendar-aurora? → approval-calendar-beta?
Attachment #665578 - Flags: approval-calendar-aurora? → approval-calendar-beta?
Comment on attachment 664807 [details] [diff] [review]
[checked in] finalize statements and close databases

Ok, I assume this is on aurora due to the merge.
Attachment #664807 - Flags: approval-calendar-beta? → approval-calendar-beta+
Attachment #665578 - Flags: approval-calendar-beta? → approval-calendar-beta+
Backported to https://hg.mozilla.org/releases/comm-beta/rev/ffe3ddad9bb8
Target Milestone: 2.0 → 1.9
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: