Closed Bug 367456 Opened 13 years ago Closed 12 years ago

Memory usage increases after Reload Remote Calendars (memory leak)


(Calendar :: Calendar Views, defect, critical)

Not set


(Not tracked)



(Reporter:, Unassigned)



(Whiteboard: [mlk?])


(6 files, 1 obsolete file)

User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv: Gecko/20061204 Firefox/
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9a2pre) Gecko/20070116 Calendar/0.6a1

I've noticed that Sunbird uses a lot of memory. In particular, the memory usage jumped by at least 20Mb (from 37.9Mb) when the Calendar view refreshed. Looks like the app is not letting go of old objects in memory

Reproducible: Always

Steps to Reproduce:
1. Start Sunbird (Memory usage = 38.5Mb)
2. Press Reload Remote Calendars (Memory usage = 55.1Mb)
3. Repeat step 2 (Memory usage = 66.3Mb)
Actual Results:  
Memory usage increases by circa 11Mb each time the remote calendars are loaded.

Expected Results:  
Memory usage should be unchanged.

I am only using local ICS files residing on my laptop's hard-drive.
I can confirm this bug using Sunbird and Lightning. I used some ics calendars from local hard disk and manually reloaded calendars to get the following data for memory usage:


Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.9a2pre) Gecko/20070118 Calendar/0.6a1:
23.1  31.7  38.9  46.1  54.6  68.2  69.9  85.3  84.0  89.9  100.3 MB

Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.9a2pre) Gecko/20070118 Thunderbird/3.0a1 with Lightning 0.6a1 (2007011803):
26.4  35.9  43.0  51.8  61.1  64.4  74.3  78.3  96.8  94.5  98.1 MB


Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv: Gecko/20070119 Calendar/0.4a1:
26.1  34.2  42.1  45.3  46.8  47.1  48.7  48.2  48.0  48.8  49.0 MB

Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv: Gecko/20070119 Thunderbird/2.0b2pre with Lightning 0.4a1 (2007011803):
28.0  36.5  43.7  45.0  46.1  47.3  47.2  47.6  49.0  48.7  49.3 MB


Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv: Gecko/20070117 Thunderbird/ with Lightning 0.4a1 (2007011803):
23.1  25.3  27.9  28.4  29.3  29.8  30.4  30.7  31.4  32.1  33.1 MB

One can see that memory usage behavior is similar in Sunbird and Lightning.
It's also noticeable that the used branch version significant influence the memory usage.
Ever confirmed: true
Whiteboard: [mlk?]
Duplicate of this bug: 366826
Might we consider upping the priority of this bug a little, please?

The numbers used increase dramatically in some cases, perhaps with basic Home SDB size. See my dup bug 366826 for numbers. This makes remote calendars unusable with Sunbird, which is a real shame.
OS: Windows XP → All
Hardware: PC → All
It may be unrelated, but I noted yesterday that my RSS also inceased from 65MB to 120MB just by adjusting a few Preferences, without restarting, and without any remote calendars loaded.
I use remote calendars on a WebDAV/Subversion server.  My memory usage peaked at 591Mb.

Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv: Gecko/20070522 Calendar/0.5pre
Flags: blocking-calendar0.5?
We are in the process of releasing 0.5 RC2. This is not serious enough to warrant an additional release delay.
Flags: blocking-calendar0.5? → blocking-calendar0.5-
Flags: blocking-calendar0.7?
Summary: Memory usage increases after Reload Remote Calendars → Memory usage increases after Reload Remote Calendars (memory leak)
I don't know, I'm with Calum on this one. Eating hundreds of MB of ram is actually fairly serious.
Duplicate of this bug: 389896
There might be a reference loop between events and their recurrence rules (bug 274793). I wonder what it does to the memory leak here if the calendar has no recurrence in any of its items.
1. Added a local ics calendar with 1 event to a clean profile. Reloaded remote calendars, memory leak of 84 KiB.
2. Added a local ics calendar with 300 events or so. Reloaded remote calendars, memory leak 8.7 MeB.
3. Imported a ics calendar with recurrence rules (once a year) and around 300 events. Reloaded remote calendars, memory leak 39 MeB
Can confirm this. Reloading 2 remote calendars, memory leaks 2.5MB each time.
Can also confirm.  We have 10 boxes running Sunbird.  Each has up to 24 calendars on it.  Memory leak and associated CPU usage (100%) causes the complete lock up of the boxes for up to 3 minutes while the calendars load.  I've seen memory leak reach 55MB on a session that's only been running for an hour, with reloads every 30 minutes.

Happens if the .ics files are located on the local drive or on a network drive.

This is serious enough for us to stop using Sunbird if it's not to be fixed.
Confirm with Build 2007093003 of Ligtning
At the end of the day I can have 1Go of RAM used by Thunderbird/Lightning !
I use many CalDAV Calendar
on each reload Ram increases of 1Mo/Calendar
This is a severe memory leak that justifies severity Critical.
Severity: normal → critical
Help fix Sunbird or my wife might revert to the calendar on the fridge!  We use Sunbird for our family via my Subversion server.

How many of us operate Sunbird continuously?  How many of us operate our computers continuously without powering off or logging off at the end of the day?  

My wife (an occasional computer user with basic computer skills) operates Sunbird continuously and the memory leak makes Sunbird unusable.  Even though the PC has 1.5 Gb RAM, if she leaves Sunbird running for a few days, the computer is consuming 100% CPU and swapping like mad.

Can we reconsider this as a severe issue for 0.7?

My instinct tells me that all the computer professionals who use Sunbird do not even notice how severe this really is.  

Should computer users be trained to open and close a web browser every time they want to surf the Internet?  Surely not.  This sounds ludicrous.

However, unless I train my wife to open and close Sunbird every time she uses it, she finds the Sunbird does not work when she returns to the computer after a couple of days.
Although this seems *not* to be the root cause of this bug, it's a leak.
Attachment #284947 - Flags: review?(mvl)
Comment on attachment 284947 [details] [diff] [review]
[checked in] property attribute setters leak

Attachment #284947 - Flags: review?(mvl) → review+
Keywords: checkin-needed
Whiteboard: [mlk?] → [mlk?][checkin-needed after 0.7]
More information:

I ran a test on one of the boxes in the office yesterday.

Calendar 0.5
20 calendar files, total size 423k
(smallest 2k, largest 72k)

Time to open:  25 minutes  (the entire box was locked up for that time)
CPU usage: 98% - 99% (For the Sunbird.exe process only)
Final memory usage: 102,300K (This was just for the startup, no reloads)
Please stop adding comments that you also see a increase in memory. we know that! No need for more data!
I looked at attachment 284947 [details] [diff] [review] and assumed that other calls to icalcomponent_remove_property() might also need a corresponding call to icalproperty_free(). I don't have enough insight into the workings of the code, but can I suggest that a developer looks at the following ...

* icalfileset.c line 776 (the recurrence property is lost)
* icalfileset.c line 841 (the recurrence property is lost)
* icalfileset.c line 910 (the recurrence property is lost)
* icalcomponent.c line 1204 (the error property is lost)
* icalcomponent.c line 1271 (the replaced error property is lost)

The first 3 points would explain why the memory leak is worse when there are recurrence rules.
Can I suggest a minor refactor? If my assessment in comment 20 is correct, there is a tendency to forget to call icalproperty_free() after icalcomponent_remove_property().

Two possibilities suggest themselves.

1. Rename icalcomponent_remove_property() to icalcomponent_detach_property() to avoid the slip of assuming that 'remove' includes 'free'.
2. Add a 3rd argument to icalcomponent_remove_property() which is a boolean indicating whether the property should be freed. Thus all current calls to icalcomponent_remove_property(c,p) become icalcomponent_remove_property(c,p,FALSE) with no immediate change in functionality. Then the argument is changed to TRUE when the property needs to be freed. This prevents the problem recurring in future.
We never use icalfileset, so that can't be the cause of any leaks. The latter two only deal with errors, and are thus not often called. Also an unlike cause of the noticed problems.
I still wonder if the memory is really leaked, or that it is just freed in such a way that the system can't use it... We need some proof of leaking objects other then the memory usage the OS reports.
Keywords: checkin-needed
Whiteboard: [mlk?][checkin-needed after 0.7] → [mlk?]
Attachment #284947 - Attachment description: property attribute setters leak → [checked in] property attribute setters leak
Attachment #284947 - Attachment is obsolete: true
Flags: blocking-calendar0.7? → wanted-calendar0.8+
(In reply to comment #23)
Would it help to analyze the issue by running Sunbird with XPCOM_MEM_LEAK_LOG or XPCOM_MEM_BLOAT_LOG enabled? If yes I could do a few test runs.
I know those flags and had a look at the leak log once, but it haven't enlightened me; thanks anyway.
I found and tried to use malloc_stats(). I hacked a bit to be able to call it, see the attached patch (sunbird only, if you want UI). Using that, it looks like sunbird indeed uses more memory on each reload. For the most dramatic effect, use a large calendar. I got "in use bytes"    to grow from 37915984 to 42742496. There is still the blurring factor of garbage collection, I need to look into that.
But the numbers indicate that there really is a memory problem, and it's not just a problem of the OS not being able to reclaim the freed memory or the OS showing wrong numbers.

I also looked where the memory was going, using some mac tools. Found nothing specific, but it seems to point to javascript things. Not really telling us much, except that it's a bit less likely that libical or our wrapper around it is the cause of the problems. But no clue as to what is the problem.
Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv: Gecko/20071023 Sunbird/0.7

I have a similar problem, but I don't use remote calendars.  I have Sunbird open on startup, and even if I just leave it for a while, the memory is consumed.  Last night I left my computer on.  When I came home from work, Sunbird was using 800+ MB or RAM.  I restarted, and in the last 1-2 hours, it's gone from ~19MB to 120MB.
I can confirm the same problem here. Both Sunbird version 0.7 and Lightning version 0.7 leak memory on Linux. This problem didn't exists with version 0.5.

Mozilla/5.0 (X11; U; Linux i686 (x86_64); en-US; rv: Gecko/20071023 Sunbird/0.7

version (20070728), with Lightning version 0.7. Running on Redhat WS4.0

It is related to the automatic reloading. When you disable that, the memory consumption stays constant over time. With reloading at 10 minutes, the memory consumption of Sunbird grows about 700MB for each 12 hours.

We have no local calendars, only remote calendars on a RSCDS caldav server.
I can also confirm the same problem.  I am using Sunbird version 0.7 and this did not occur with version 0.5.  I also am only using remote calendars on a RSCDS caldav server as the previous comment stated.

I think that this should be moved up in priority because it makes sunbird unusable.  I have tried using version 0.5, but the reload does not work.
I tested this with 9 different builds (November 5th 2007 - March 5th 2007, one build a month) to find a regression range with a large (250K) local .ics calendar provided by mvl and this happens in all of the builds.

It actually gets worse the more you go back. In the November or October builds, the memory usage would go up, but level at around 60 MB. In the March build I can bring the memory usage up to over 70 MB before it reaches its peak level.

If this is a regression, then it is not a recent one.

I tested on WinXP with both a fresh profile (created in the March build) and my working profile. No difference there though.
This is in response to Comment #30.  Your test was using a local .ics file.  However, this bug is for remote calendars.  In particular, remote calendars residing on a caldav server (I'm not sure about webdav).  Also, the memory usage keeps going up well above 70 MB.  In fact, mine was using over 700 MB before I killed it.
It would be an interesting experiment to see if the type of calendar provider makes any difference. Especially comparing caldav to gdata, because they both use the same method of refreshing a calendar, but gdata doesn't do anything with ics. It might show if there is a problem in the front-end, or if it is more back-end related.
For the best test, the same calendar data should be used.
Anyone up for such a test?
In response to Comment #31, This problem still exists, even when you do not use remote calendars.  I use NO remote calendars, only local, but I still have memory problems (in the order of 500MB/day).

Just so that this aspect of the problem is looked at, should I create a new bug report, or would it be considered the same as this bug?
No, don't file a new bug. We don't really know what the problem is anyway. It might be remote calendars, it might not, it might be more then one problem.

And once again: Please, please, please, don't comment anymore to confirm this bug, or to quote your memory usage. We know about it! All the comments just hide the comments that actually try to fix the bug.
Here you see two memory graphes I tracked for gdata, which doesn't do much ICS processing. The profile was fresh and I removed all other calendars (i.e the Home calendar). There is definitely some increase in memory usage when reloading remote calendars even here.

If needed I can do the same test with an ics calendar f.e.
Actually, the ICS is quite interesting. Reload remote calendars goes in steps, not recovering from the extra memory. This was done after restarting with the same profile but all calendars except for the ics calendar removed.
Those graphs are a bit hard to interpret, because there is no scale information on the time axis.
And if there were, there is still the issue of Garbage Collection. I suspect that the time between the reloads is not that large. This makes it unlikely that GC was run between the reloads. I think you can force GC using venkman. I don't know the details though.
(In reply to comment #38)
> that GC was run between the reloads. I think you can force GC using venkman. I
> don't know the details though.
Command is: /gc
I ran lightning and sunbird, both using a clean profile. I subscribed to an ics file, and set it to reload every 2 minutes. I checked the memory usage during the test, the result is in the attached file. test done on a macbook, recent 1.8-branch builds. (self-compiled)

My conclusions: both apps have their memory usage increased during the load. It doesn't matter if there is anything visible in the views. When the ics file is much smaller, there is no noticeable memory increase.
The fix for bug 410168 was checked in yesterday and nightly builds containing the patch are available now. 

It would be great, if someone could download a nightly build to find out, whether our memory usage story with remote calendars has improved or not.
I downloaded the latest lightning nightly and installed it about 1 hour ago.  Unfortunately I'm not seeing any improvement in the memory usage.  I load 3 remote CALDAV calendars and, initially Thunderbird memory starts at about 60MB.  I set the calendars to reload every 10 minutes and it is currently sitting at about 240MB (and still growing I think).
I downloaded the latest lightning nightly and installed it about 1 hour ago. 
Unfortunately I'm not seeing any improvement in the memory usage.  I load 18
remote CALDAV calendars and, initially Thunderbird memory starts at about 60MB.
I'm now at 140 MB, at each reload the memory increased about 5MB
Flags: blocking-calendar0.5-
I have three remote ICS calendar in addition to the default local one.  Here's what I see when periodically running top while continuously running today's nightly build (Mozilla/5.0 (X11; U; Linux i686; en-US; rv: Gecko/20080115 Calendar/0.8pre):


 6310 myk       15   0  122m  50m  18m S    0  5.0   0:08.04 sunbird-bin

 6310 myk       15   0  142m  62m  18m S    0  6.2   0:26.52 sunbird-bin

 6310 myk       15   0  148m  68m  18m S    0  6.7   0:37.21 sunbird-bin

 6310 myk       15   0  157m  76m  18m S    0  7.6   0:50.49 sunbird-bin
(In reply to comment #41)

> It would be great, if someone could download a nightly build to find out,
> whether our memory usage story with remote calendars has improved or not.

I have tried the nightly build from before and after and my users are still reporting the memory leak. Tested myself and upon reload of the remote calendar it still increases by about 11meg per reload.
I don't mean to rant, but I don't understand how a bug this problematic is not being actively worked on.  I am a software engineer myself (although I do not have time to work on a project like this) and if my company released something like this we would really hear it from our customers.  If you know that there is a memory leak in your program that makes it unusable, how is this not the first thing fixed?

Yes, you guys do a great thing dedicating your time to give us free software, but this unacceptable.  I know that I am going to hear it from people about my comment and that there are thousands of other bugs, etc., but I just wanted to get my frustrations out there.  I think this bug is the final straw that broke the camel's back and is sending my company to Exchange/Outlook.
(In reply to comment #46)

Go ahead.  Rant.  You have at least one person cheering you on.
(In reply to comment #47)
> (In reply to comment #46)
> Go ahead.  Rant.  You have at least one person cheering you on.

I want this bug fixed, too.  It's one of two bugs preventing me from using Lightning regularly.  But please don't rant, because doing so won't help fix the bug; if anything, it'll hurt the effort.  Instead, follow Bugzilla etiquette <>.
I have been noticing this with Thunderbird and Lightning 0.7 on Windows XP.  I tend to leave TB running all the time.  It starts out using about 45MB of memory when I first launch it but seems to grow over time.  I just caught it using 350MB a little while ago - probably had been running for a week.
Duplicate of this bug: 424807
Duplicate of this bug: 417431
Flags: wanted-calendar0.8+ → wanted-calendar0.9+
I am having trouble duplicating the memory leak behaviour on trunk with Lightning (and Thunderbird) on OS X.  This is with a local calendar and two 'remote' (one is file://, one is http://) ics files, and "refresh calendars every" 1 minutes.

I do see memory usage bloat during processing (up to 70 megs in my case), but within 15 seconds of processing completing, the real and virtual memory come back down again.  I think performance could be improved, but I don't think the leak exists anymore (on trunk).
Attached image Memory usage LT2008053119 β€”
I've got 12 calendars with and without recurring events running Lightning 2008053119 on TB and can't confirm the bug anymore either, see attached graph of memory-usage.
Thanks for helping, Andrew. Bas, I can still experience the problem on branch.

FWIW, my status update:
I started valgrinding (--leak-check=full) a bit, but my sunbird process always hangs when I try to close down the app (and collect the leaks :/ ). Valgrinding the unit tests (which use the providers, ics-service) hasn't provided any libical etc leaks, only some XPCOM/XPC leaks.
Looking at the XPC_SHUTDOWN heap dump after running Sunbird, it gives me a hell of a log; I've grepped for calendar js code, but found only strings, functions.
I am not sure if this leak is any related but...
if it helps I've installed leak monitor to be ale to detect leaks. When I double click on any of my e-mail messages to open the message in a new window and then close this window LeakMonitor detects some leaks. I am using LeakMonitor 0.3.6, Thunderbird and Lightning nightly build 2008053019. Below is the output that LeakMonitor detects:

Leaks in window 0x32f4578:
[+] [leaked object] (3686428) = [Object]
 [+] onStartHeaders (3686420, chrome://messenger/content/msgHdrViewOverlay.js, 263-293) = [Function]
  [ ] prototype (31bd9f0) = [Object]
 [+] onEndHeaders (3686418, chrome://messenger/content/msgHdrViewOverlay.js, 297-312) = [Function]
  [ ] prototype (31bda78) = [Object]
 [+] processHeaders (3686410, chrome://messenger/content/msgHdrViewOverlay.js, 316-383) = [Function]
  [ ] prototype (31bda88) = [Object]
 [+] handleAttachment (3686408, chrome://messenger/content/msgHdrViewOverlay.js, 387-424) = [Function]
  [ ] prototype (31bda98) = [Object]
 [+] onEndAllAttachments (36863f8, chrome://messenger/content/msgHdrViewOverlay.js, 430-431) = [Function]
  [ ] prototype (31bdaa8) = [Object]
 [+] onEndMsgDownload (36863f0, chrome://messenger/content/msgHdrViewOverlay.js, 435-449) = [Function]
  [ ] prototype (31bdab8) = [Object]
 [+] onEndMsgHeaders (36863e8, chrome://messenger/content/msgHdrViewOverlay.js, 453-454) = [Function]
  [ ] prototype (31bdae0) = [Object]
 [+] onMsgHasRemoteContent (36863e0, chrome://messenger/content/msgHdrViewOverlay.js, 458-459) = [Function]
  [ ] prototype (31bdaf0) = [Object]
 [+] mSecurityInfo (38edae0) = [XPCWrappedNative_NoHelper]
  [+] QueryInterface (31bdb18) = [Function]
   [ ] prototype (31bd9d0) = [Object]
 [+] mSaveHdr (3946040) = [XPCWrappedNative_NoHelper]
  [ ] messageKey = true
  [ ] getStringProperty (3945088) = [Function]
  [ ] isRead = true
  [ ] messageId = true
  [ ] flags = true
  [ ] markHasAttachments (3944e80) = [Function]
  [ ] getUint32Property (3944e78) = [Function]
  [+] QueryInterface (2c58f00) = [Function]
   [ ] prototype (31bc638) = [Object]
  [+] getProperty (2f09a80) = [Function]
   [ ] prototype (31bc658) = [Object]
  [+] setProperty (2f09a60) = [Function]
   [ ] prototype (31bc698) = [Object]
  [+] setStringProperty (2f09a50) = [Function]
   [ ] prototype (31bc6b0) = [Object]
  [+] setUint32Property (2f09a40) = [Function]
   [ ] prototype (31bc6c0) = [Object]
  [ ] isFlagged = true
  [+] markRead (2f09a20) = [Function]
   [ ] prototype (31bc6e8) = [Object]
  [+] markFlagged (2f099f8) = [Function]
   [ ] prototype (31bc6f8) = [Object]
  [ ] priority = true
  [+] setPriorityString (2f099c8) = [Function]
   [ ] prototype (31bcfc8) = [Object]
  [+] OrFlags (2f09910) = [Function]
   [ ] prototype (31bd010) = [Object]
  [+] AndFlags (2f098e8) = [Function]
   [ ] prototype (31bd038) = [Object]
  [ ] threadId = true
  [ ] threadParent = true
  [ ] messageSize = true
  [ ] lineCount = true
  [ ] statusOffset = true
  [ ] messageOffset = true
  [ ] offlineMessageSize = true
  [ ] date = true
  [ ] dateInSeconds = true
  [ ] ccList = true
  [ ] author = true
  [ ] subject = true
  [ ] recipients = true
  [+] setReferences (3095a38) = [Function]
   [ ] prototype (31bd920) = [Object]
  [ ] numReferences = true
  [+] getStringReference (31bdd68) = [Function]
   [ ] prototype (31bd968) = [Object]
  [+] setRecipientsArray (31bdd38) = [Function]
   [ ] prototype (31bd990) = [Object]
  [+] setCCListArray (31bdd20) = [Function]
   [ ] prototype (31bd9a8) = [Object]
  [ ] mime2DecodedAuthor = true
  [ ] mime2DecodedSubject = true
  [ ] mime2DecodedRecipients = true
  [ ] Charset = true
  [ ] label = true
  [ ] accountKey = true
  [ ] folder = true
 [ ] securityInfo = true
 [ ] mDummyMsgHeader = null
 [+] getDummyMsgHeader (36863c0, chrome://messenger/content/msgHdrViewOverlay.js, 476-479) = [Function]
  [ ] prototype (1517368) = [Object]
 [ ] mProperties = null
 [ ] properties = true
[+] [leaked object] (36860f8) = [Object]
 [+] maxWantedNesting (36860f0, chrome://messenger-smime/content/msgHdrViewSMIMEOverlay.js, 21-22) = [Function]
  [ ] prototype (3263750) = [Object]
 [+] signedStatus (36860e8, chrome://messenger-smime/content/msgHdrViewSMIMEOverlay.js, 26-58) = [Function]
  [ ] prototype (3263760) = [Object]
 [+] encryptionStatus (36860d8, chrome://messenger-smime/content/msgHdrViewSMIMEOverlay.js, 63-113) = [Function]
  [ ] prototype (3263780) = [Object]
 [+] QueryInterface (36860c0, chrome://messenger-smime/content/msgHdrViewSMIMEOverlay.js, 118-121) = [Function]
  [ ] prototype (31bc538) = [Object]
[ ] [leaked object] (38ee518) = [Object]
[ ] [leaked object] (38ee518) = [Object]
(In reply to comment #55)
> I am not sure if this leak is any related but...

Not related because it only contains Thunderbird leaks and nothing related to Lightning.
My current feeling is that there is not so much a memory leak (one that valgrind would find), but some reference cycle, likely between JS and C++ objects. This causes at least parts of the old calendar objects to stay in memory when a reload happens. As a result, the memory usage increases. But on shutdown, all the objects might get cleanly disposed. (my previous experiments with valgrind didn't find anything)
This idea is based on the observation that trunk has no memory leak. This might very likely be due to the cycle collector. Branch doesn't have that, so cycles are not cleared.

So, I would start to look for cycles like this. Maybe the cycle collector on trunk can tell which cycles it found. Then I would try to fix those cycles manually (for branch)
bug 423172 was solved, as are some other memory-related bugs. How is this behaviour now?
Bas: I think this bug is also fixed. The STRs in the description are one of my testscenarios to verify 423172. So we could change the resolution of this issue to WFM, too.
Resolving FIXED per comment #59.
Closed: 12 years ago
Resolution: --- → FIXED
You need to log in before you can comment on or make changes to this bug.