Closed Bug 519226 Opened 15 years ago Closed 14 years ago

thunderbird 3 has extremely high memory requirements on Linux (Enigmail is used)

Categories

(Thunderbird :: General, defect)

Product:
Thunderbird
Component:
General
Platform:
x86
Linux
Type:
defect
Priority:
Not set
Severity:
major

Tracking

(Not tracked)

Status:
RESOLVED INVALID

People

(Reporter: asac, Assigned: asuth)

Details

(Keywords: perf, Whiteboard: [add-on]) 

Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.1.4pre) Gecko/20090927 Shredder/3.0pre

my setup is a two gmail/map account setup with total amount of mails summing up to 150k.

Obviously not a small mail setup, but shouldn't be too unusual

After using thunderbird 3 for a few minutes (reading like 20-50 mails), it starts to fully utilize the mem of this 2GB system to the point where i wasn't able to have any other app (like firefox) running without starting to swap to disk.

From what i understood this is being investigated, so I just file this bug with my ubuntu hat on to express my feeling that this should to be improved for release. hence, requesting blocking-thunderbird3.
Flags: blocking-thunderbird3?
Keywords: perf
Assignee: nobody → bugmail
Flags: blocking-thunderbird3? → blocking-thunderbird3+
How many messages are in the folders with the most messages? Can you check to see how many .msf files TB has open once you get into this state, and their sizes? I'd like to know how much of is due to having more .msf files open than we should.
Whiteboard: [no l10n impact]
I observed "huge virtual memory size" on MS Win with Tb3.0b4 9/25 build and 9/30 build.
(0) No add-on, standard Theme. Nealy same as new profile with some customize.
    Gloda=off, auto-sync=off, All IMAP folders is set to "offline use = off".
    Gmai IMAP. An IMAP folder has 4096 mails. 1KB per a mail.
    All mails has different Subject: (to rule out problem by long/deep thread)
(1) Select All, Copy to another Gmail IMAP folder.
    Maximum real memory size is around 120MB, but is not observed so long time.
    Real memory size is 40MB to 80MB while copying, except some peaks of 120 MB.
    Virtual memory size rapidly grows. Max virtual memory size is 1350MB,
    and it continues while long copy process(PC of 1GB memory. Swapping by OS is
    probably main reason of heavy slowness.)
(2) Long copy ends.
    Virtual memory size decreases but to around 1250MB.
    It won't be reduced by ordinal operation such as folder open, close.
    Real memory size is around 60MB, and no delay at UI.
(3) Context menu of account or folder, Open -> New Tb window is opened.
(4) Close old Tb window.
    -> Virtual memory size starts to decrease, and finally becomes 64MB.
Such huge VM size can be observed by move/delete operation of many small(1KB) mails too.

If phenomenon of this bug is similar pseudo memory leak, "new Tb window open followed by old Tb window close" will reduce virtual memory size.
What will happen when old window is closed in your case?
Phenomenon of comment #2 was observed with Tb3.0(1.9.1) 9/02 build too(slowness of copy was worse than 9/25, 9/30 build.)
Alexander Sack, did your problem start to occur from which build?
this sounds like gloda indexing and is easily tested.
asac, what happens if you turn off indexing in options>advanced>general?
Version: unspecified → 3.0
Mine started in last 7 or so days. i think i noticed it with Sunday's build.
I am unable to find an options menu, Can you please point me to where it is
John, uncheck "Enable Global Search and Indexer"
Thanks i found it. I will test this in a few minutes and update the bug.
Alexander did it work for you?
no this did not fix the issue in version
3.0~hg20091014r4145+nobinonly-0ubuntu1~umd1
if it helped at all it was not noticeable
Alexander, can you clarify your account situation and the distribution of mails across folders and a few other things?:

1) Are you saying you have 2 gmail IMAP accounts or a gmail (IMAP) and another IMAP?

2) How are you estimating your message counts.  Is this based on Thunderbird or another IMAP client, or are you getting that from gmail?  In case it's gmail, please be very sure you're not talking about conversations rather than messages.

3) Do you use labels a lot?  Do you have labels with a lot of conversations/messages in them?

4) Is this an amd64 build?  (I'm guessing that it is...)


bienvenu, do you have a ballpark estimate for what the in-memory footprint of a message header is in terms of mork usage, and with 64-bit pointers?


Right now there is nothing actionable on this bug, although I will check back again after I land the gloda correctness fixes or if new information is reported.
Whiteboard: [no l10n impact] → [no l10n impact][check after gloda correctness patch lands]
Target Milestone: --- → Thunderbird 3.0rc1
Copying 4000 messages in one go to an other folder is very different from the initial report, which involves reading from 20-50 messages.

I've looked into the 4000 message case - we're creating undo objects for each message, and that really seems to explode memory, along with the notifications we send. I would have thought we'd just create a single undo object but imap offline moves don't seem to work that way.
asac, can you reproduce this with indexing turned off?  If it goes away, do you see this with tryserver build and indexing turned on?   ... ludovic's 4 entries near bottom of http://s3.mozillamessaging.com/build/try-server/list.html
Alexander, you're using Enigmail if I'm not mistaken? I noticed that on Linux decrypting a PGP/MIME message eats 50 - 100 MB of RAM (only for the 1st time after startup, afterwards the message seems to be cached). Inline-PGP messages don't do that.

I compared this with Windows and it doesn't happen there.

I'm a bit puzzled because even though there is some C++ code involved for PGP/MIME messages, there is nothing platform-specific that wouldn't be done with inline-PGP messages.
One other path :
Xref bug  516395.

Can you set mail.check_all_imap_folders_for_new to false and see if your memory
issue goes away ?
dmose, standard8, I doubt this needs to stay blocking. As yet, the cause is still unknown. Plus it doesn't appear to be widespread issue.  

for ~1.5 hour I set mail.check_all_imap_folders_for_new true on a TB2 install and a TB3 install - I am am not seeing any steady increase in memory.  So the issue may be some other combination of triggers
I agree with Wayne's assessment.  I don't think we have anything that's concrete enough to block on at this point.  More feedback from asac based on the various questions in the bug after the correctness patch lands may help us here or may not; it's hard to guess.  Feel free to renominate if we get to something firmer.

bienvenu/WADA: sounds like copying the 4000 messages issue should be spun off to another bug.  I suspect that wouldn't be blocker, but it would certainly be worth considering taking if a low-risk patch were to appear...
Flags: blocking-thunderbird3+ → blocking-thunderbird3-
Bug 525646 is already filed for the large imap copy issue.
I'm not sure if "blocking-thunderbird3-" is the right decision here. I did some comparison between TB 2 and Shredder on Linux, using official Thunderbird builds from mozilla.org (Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.1.6pre) Gecko/20091105 Shredder/3.0pre). I disabled Gloda for this purpose.

1. Start Thunderbird with -safe-mode and open the Error Console
2. The the following statement in the code field:
"var a=[]; for (i=0; i<100000; i++) { a[i] = "Hello World This is a test "+i }; a=null"
3. click 15 times on "Evaluate", waiting ca. 1 second between each click.

Resulting memory consumption:
                         TB2    TB3
After Start:            100M   160M
After evaluating:       114M   207M

Observation: 
TB2: virtual memory grew temporarily a bit and shrunk again after 1-2 seconds.

Shredder: virtual memory consumption grew with ca. every 2nd click. Once the memory was allocated, it was never released anymore. I have never ever seen any reduction of virtual memory with Shredder, also not with my production mail.
Severity: normal → major
Keywords: testcase
can't reproduce on windows
Summary: thunderbird 3 has high memory requirements (on ubuntu) → thunderbird 3 has high memory requirements on Linux
On Mozilla/5.0 (X11; U; Linux i686; pl; rv:1.9.1.5pre) Gecko/20091026
Shredder/3.0pre:

At start: 255m Virtual, 48m Resident
At end: 294m Virtual, 68m Resident
A few seconds after end: 291m Virtual, 49m Resident

On Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.1.6pre) Gecko/20091105
Shiretoko/3.5.6pre:

At start: 206m Virtual, 49m Resident
At end: 251m Virtual, 92m Resident
A few seconds after end: 251m Virtual, 50m Resident

On Thunderbird version 2.0.0.23 (20090812) - en-US downloaded from
www.mozillamessaging.com:

At start: 124m Virtual, 30m Resident
At end: 140m Virtual, 46m Resident
A few seconds after end: 139m Virtual, 45m Resident

I tried TB 2 a couple of times the first time there was no drop in either
virtual or resident, the second time shown above there was a 1Mb drop.

This is on CentOS 5 in a Virtual Machine (which is what our tinderboxes
currently use).

So from where I'm looking with the testcase, TB 3 is actually an improvement
because the resident memory usage goes down nearly all the way.
The problem is that the virtual memory consumption increases quite quickly until 2.7 - 2.9 GB are reached (on a 32-bit system). At this point Thunderbird becomes unusable.

I have started Shredder this morning at work; after 3.5 hours of infrequent usage, my memory stats are:
Virtual: 2036m
Resident: 146m

So yes, Resident memory is perfectly fine, but virtual memory consumption is an issue.
(In reply to comment #20)
> So yes, Resident memory is perfectly fine, but virtual memory consumption is an
> issue.

My comment wasn't to point at resident memory being fine, but to point out that a) your results with your test case are different to mine and b) my results shows that Thunderbird behaviour compares with the results in Firefox.

So if your testcase is really the test case we're investigating here (and I'm not sure it is) then this would be a core bug.

Have you also monitored the equivalent Firefox version (3.5) to see if that has the same issue?
Sorry, I should have been more clear when describing my test case. I was mainly looking a virtual memory, because this seems to be my hurting problem (at least when using Enigmail, whenever you decrypt a PGP/MIME message, 30-60 MB of virtual memory are aquired until 2973m is reached).

I just did some tests with Firefox 3.5.5 and it shows very similar results with not releasing Virtual memory. I agree, this looks like a core bug -- should I open a new bug for this, as it seems that it's a different topic?
(In reply to comment #22)
 
> I just did some tests with Firefox 3.5.5 and it shows very similar results with
> not releasing Virtual memory. I agree, this looks like a core bug -- should I
> open a new bug for this, as it seems that it's a different topic?

Let's see what Asac as to say . And then we can just move this bug.
In the interest of time I would rather suggest filing a new bug on what we know because a) we have no clue when asac will respond, and we don't know whether what we have found is his issue and b) I'd rather keep a bug (this bug) open in thunderbird so the issue is findable for TB users, and have a core bug blocking this if necessary.
(In reply to comment #20)
> The problem is that the virtual memory consumption increases quite quickly
> until 2.7 - 2.9 GB are reached (on a 32-bit system). At this point Thunderbird
> becomes unusable.

In what way is it unusable?  This itself sounds like it could yet another separate bug.
Once all virtual memory is used (which appears to be at 2973m on my system), then various actions will start to fail. 

I just produced such a situation, and if I now try to open a new tab with a 3-pane view I receive an empty tab.

If the error console is open, you might see strange errors like "parentPart is undefined" (from jsmimeemitter.js) "console.targetWindow is null" (from Venkman) or "this.attachFormFillis not a function" (from browser.xml). I assume (but I'm not an expert in this!) that this is because malloc or similar operations fail because memory management tries to acquire new virtual memory instead of reusing existing VM, which apparently fails.
The growth of the virtual memory would not be a major problem if it was just a high water mark with the memory allocator never freeing memory, but it sounds like Patrick is encountering either an actual memory leak or simply using up memory faster than the garbage collection passes can claim it, resulting in an absurdly high high water mark.

Patrick, can you try inserting calls to:
1) Components.utils.forceGC
and then
2) nsIDOMWindowUtils.forceGC
between whatever action you are taking?

This would help determine if the problem is:
1) Just that XPConnect is holding onto things too much
2) That there is a complex cycle involved...
3) (That there may just be a leak or something)
Patrick, this is always with enigmail installed, I assume. Is it possible that enigmail is inadvertently causing some sort of memory bloat by causing objects to be held onto, e.g., because of cycles, as asuth mentioned.
(In reply to comment #27)
> The growth of the virtual memory would not be a major problem if it was just a
> high water mark with the memory allocator never freeing memory, but it sounds
> like Patrick is encountering either an actual memory leak or simply using up
> memory faster than the garbage collection passes can claim it, resulting in an
> absurdly high high water mark.

I don't think that speed is an issue. You can wait as long as you like, the VM size is never reduced or recycled.

> Patrick, can you try inserting calls to:
> 1) Components.utils.forceGC
> and then
> 2) nsIDOMWindowUtils.forceGC
> between whatever action you are taking?
>
> This would help determine if the problem is:
> 1) Just that XPConnect is holding onto things too much
> 2) That there is a complex cycle involved...
> 3) (That there may just be a leak or something)

I tried this already before starting to comment on the bug -- unfortunately it has no effect at all.


(In reply to comment #28)
> Patrick, this is always with enigmail installed, I assume. Is it possible that
> enigmail is inadvertently causing some sort of memory bloat by causing objects
> to be held onto, e.g., because of cycles, as asuth mentioned.

Yes, Enigmail is always involved in my operations. I have considered that it could be Enigmail too, but then I wonder why it would only happen on Linux. I have tried the same on Windows, and this doesn't seem to happen there.

I'll try to prepare an example that doesn't involve Enigmail to see if it's really Enigmail or if something is fundamentally broken.
(In reply to comment #29)
> I don't think that speed is an issue. You can wait as long as you like, the VM
> size is never reduced or recycled.

This sounds very bad, like mismatched memory allocators or such.

Since you are using stock shredder builds, the other obvious variable is the linux distro/glibc in use.  What linux distro, what release, what architecture?

What does "ldd thunderbird-bin" return?

Are you sure your linux environment does not include any LD_PRELOAD or any other LD_ directives that might cause horrible things to happen?  The output of 'env | grep "^LD_.*"' would be what I would be looking for.
I'm running Ubuntu 9.04 (kernel 2.6.28) and 9.10 (kernel 2.6.31) on 2 different notebooks, both x86-32.

This is the output of ./run-mozilla.sh /usr/bin/ldd thunderbird-bin:

linux-gate.so.1 =>  (0x0040c000)
libpthread.so.0 => /lib/tls/i686/cmov/libpthread.so.0 (0x00ea8000)
libmozjs.so => ./libmozjs.so (0x00a68000)
libxpcom.so => ./libxpcom.so (0x00707000)
libxpcom_core.so => ./libxpcom_core.so (0x00110000)
libplds4.so => ./libplds4.so (0x00196000)
libplc4.so => ./libplc4.so (0x00458000)
libnspr4.so => ./libnspr4.so (0x00e1c000)
libdl.so.2 => /lib/tls/i686/cmov/libdl.so.2 (0x00199000)
libgtk-x11-2.0.so.0 => /usr/lib/libgtk-x11-2.0.so.0 (0x00ec1000)
libatk-1.0.so.0 => /usr/lib/libatk-1.0.so.0 (0x00b52000)
libgdk-x11-2.0.so.0 => /usr/lib/libgdk-x11-2.0.so.0 (0x008a3000)
libgdk_pixbuf-2.0.so.0 => /usr/lib/libgdk_pixbuf-2.0.so.0 (0x0019d000)
libpangocairo-1.0.so.0 => /usr/lib/libpangocairo-1.0.so.0 (0x00ddc000)
libpango-1.0.so.0 => /usr/lib/libpango-1.0.so.0 (0x00766000)
libcairo.so.2 => /usr/lib/libcairo.so.2 (0x00495000)
libgobject-2.0.so.0 => /usr/lib/libgobject-2.0.so.0 (0x001b7000)
libgmodule-2.0.so.0 => /usr/lib/libgmodule-2.0.so.0 (0x00d0b000)
libglib-2.0.so.0 => /lib/libglib-2.0.so.0 (0x001f5000)
libX11.so.6 => /usr/lib/libX11.so.6 (0x002ab000)
libdbus-glib-1.so.2 => /usr/lib/libdbus-glib-1.so.2 (0x006e1000)
libdbus-1.so.3 => /lib/libdbus-1.so.3 (0x0040d000)
libm.so.6 => /lib/tls/i686/cmov/libm.so.6 (0x00a1b000)
libsmime3.so => ./libsmime3.so (0x00848000)
libssl3.so => ./libssl3.so (0x00d3c000)
libnss3.so => ./libnss3.so (0x00bf2000)
libnssutil3.so => ./libnssutil3.so (0x003da000)
libsoftokn3.so => ./libsoftokn3.so (0x006a9000)
libldap60.so => ./libldap60.so (0x0045c000)
libprldap60.so => ./libprldap60.so (0x003ee000)
libldif60.so => ./libldif60.so (0x00711000)
libXrender.so.1 => /usr/lib/libXrender.so.1 (0x007b0000)
libfreetype.so.6 => /usr/lib/libfreetype.so.6 (0x0051c000)
libfontconfig.so.1 => /usr/lib/libfontconfig.so.1 (0x005bc000)
libXt.so.6 => /usr/lib/libXt.so.6 (0x005e9000)
libgthread-2.0.so.0 => /usr/lib/libgthread-2.0.so.0 (0x009b4000)
libpangoft2-1.0.so.0 => /usr/lib/libpangoft2-1.0.so.0 (0x0063c000)
libsqlite3.so => ./libsqlite3.so (0x00938000)
libasound.so.2 => /usr/lib/libasound.so.2 (0x075fd000)
libstdc++.so.6 => /usr/lib/libstdc++.so.6 (0x09903000)
libgcc_s.so.1 => /lib/libgcc_s.so.1 (0x0059b000)
libc.so.6 => /lib/tls/i686/cmov/libc.so.6 (0x042dd000)
/lib/ld-linux.so.2 (0x007f8000)
libXcomposite.so.1 => /usr/lib/libXcomposite.so.1 (0x007ef000)
libXdamage.so.1 => /usr/lib/libXdamage.so.1 (0x003f3000)
libXfixes.so.3 => /usr/lib/libXfixes.so.3 (0x003f6000)
libgio-2.0.so.0 => /usr/lib/libgio-2.0.so.0 (0x04b1f000)
libXext.so.6 => /usr/lib/libXext.so.6 (0x003fc000)
libXinerama.so.1 => /usr/lib/libXinerama.so.1 (0x00446000)
libXi.so.6 => /usr/lib/libXi.so.6 (0x00b70000)
libXrandr.so.2 => /usr/lib/libXrandr.so.2 (0x00449000)
libXcursor.so.1 => /usr/lib/libXcursor.so.1 (0x00dff000)
libz.so.1 => /lib/libz.so.1 (0x00665000)
libpixman-1.so.0 => /usr/lib/libpixman-1.so.0 (0x00714000)
libdirectfb-1.2.so.0 => /usr/lib/libdirectfb-1.2.so.0 (0x0359a000)
libfusion-1.2.so.0 => /usr/lib/libfusion-1.2.so.0 (0x0048b000)
libdirect-1.2.so.0 => /usr/lib/libdirect-1.2.so.0 (0x0067b000)
libpng12.so.0 => /usr/lib/libpng12.so.0 (0x007ba000)
libxcb-render-util.so.0 => /usr/lib/libxcb-render-util.so.0 (0x00452000)
libxcb-render.so.0 => /usr/lib/libxcb-render.so.0 (0x00693000)
libxcb.so.1 => /usr/lib/libxcb.so.1 (0x00815000)
libpcre.so.3 => /lib/libpcre.so.3 (0x00866000)
librt.so.1 => /lib/tls/i686/cmov/librt.so.1 (0x0069c000)
libexpat.so.1 => /lib/libexpat.so.1 (0x009ba000)
libSM.so.6 => /usr/lib/libSM.so.6 (0x006d8000)
libresolv.so.2 => /lib/tls/i686/cmov/libresolv.so.2 (0x00833000)
libselinux.so.1 => /lib/libselinux.so.1 (0x00b99000)
libXau.so.6 => /usr/lib/libXau.so.6 (0x006a5000)
libXdmcp.so.6 => /usr/lib/libXdmcp.so.6 (0x006ff000)
libICE.so.6 => /usr/lib/libICE.so.6 (0x009e1000)
libuuid.so.1 => /lib/libuuid.so.1 (0x0070b000)

There is no LD_* env. var defined.
(In reply to comment #31)
> This is the output of ./run-mozilla.sh /usr/bin/ldd thunderbird-bin:

Fancy ;).  "./thunderbird -g -d ldd" also works too.

That had no red flags, which leaves suspicious dynamically loaded plugins and XPCOM stuff.  Can you do something along the lines of "cat /proc/`pgrep thunderbird-bin`/maps" after triggering some memory leakage (to make sure that anything suspicious is loaded) and paste/attach that up here?
I think I can prove that Thunderbird / Core behaves correctly.

I have created below example which I executed on a message with ca 10 MB size:

memtstLoadLoop(0);

function memtstLoadLoop(counter) {
  if (counter > 100) {
    dump("Count reached: "+counter);
    return;
  }

  var cbObj = {
    counter: counter
  };

  try {  
    MsgHdrToMimeMessage(gFolderDisplay.selectedMessage , cbObj, 
          memtstCallback, true);
  }
  catch(ex) {}
}

function memtstCallback(msg, mimeMsg) {
  memtstLoadLoop(this.counter+1);
}

During the processing TB acquired up to 800 MB of virtual memory; after the recursion loop is over, VM went back to ca. 300 MB. The bad news for me 2 is that this implies some bug(s) in Enigmail ...
An update on my virtual memory issue: I found that for each message to decrypt Enigmail started 2-4 threads which were never terminated (the threads were correctly terminated in TB 2). Obviously this will consume more and more virtual memory. I have fixed this, so the memory consumption on Linux remains now stable and nicely low for me.

I can't tell though if this is what asac experienced...
someone filed a bug about ghost threads on linux - it sounds quite possible they were using enigmail. I'll try to find that bug.
Whiteboard: [no l10n impact][check after gloda correctness patch lands] → [needs reporter retest][enigmail?]
(In reply to comment #35)
> someone filed a bug about ghost threads on linux - it sounds quite possible
> they were using enigmail. I'll try to find that bug.

bienvenu, any luck?
No, I couldn't find that bug.
asac, does Patrick's analysis hold up for your reproduction of this issue?
asac, if you are able you would want to retest with 3.1 branch and do a quick spin through https://wiki.mozilla.org/Thunderbird:Testing:Memory_Usage_Problems ... without feedback we can't determine the cause of this report and will close in 3 weeks.
Keywords: testcase
Whiteboard: [needs reporter retest][enigmail?] → [closeme 2010-03-03]
(In reply to comment #37)
> No, I couldn't find that bug. [about ghost threads]

bienvenu, perhaps you were thinking of Bug 506421?
but he claims to not have any extensions and tested in safe mode.

bug 533464 comment 21 mentions ghost threads in linux (and enigmail) but seems unlikely to be the bug you were thinking of

I suppose if we don't hear from asac we might take a leap of faith - blame it on enigmail and close this invalid.  But would enigmail really cause such extreme usage by reading only 20-50 messages, per comment 0?  

I'm not clear how much memory Patrick is cites per click/view in comment 17 ... but it would have to be ~50MB per message for magnitude to equal what asac was seeing.
Summary: thunderbird 3 has high memory requirements on Linux → thunderbird 3 has extremely high memory requirements on Linux
Target Milestone: Thunderbird 3.0rc1 → ---
wsmwk - ghost, zombies, yes, that's the bug I was thinking of.
Adding "Enigmail" to bug summary for ease of search.
Summary: thunderbird 3 has extremely high memory requirements on Linux → thunderbird 3 has extremely high memory requirements on Linux (Enigmail is used)
To Alexander Sack8bug opener):
Do you use next option or enable "Check this for neww message" of many IMAP folders? (Folder Properties/General Information) 
> mail.check_all_imap_folders_for_new=true
If yes, Bug 540214 also occurs.
(In reply to comment #41)
> I suppose if we don't hear from asac we might take a leap of faith - blame it
> on enigmail and close this invalid.  But would enigmail really cause such
> extreme usage by reading only 20-50 messages, per comment 0?  
>
> I'm not clear how much memory Patrick is cites per click/view in comment 17 ...
> but it would have to be ~50MB per message for magnitude to equal what asac was
> seeing.

From my own experience: yes, 20-50 messages are enough to consume all memory.
So, best theory is it's Enigmail = close invalid.
and if not, then it's bug 540214 or something we can't know without asac feedback.

so => invalid
Status: NEW → RESOLVED
Closed: 14 years ago
Resolution: --- → INVALID
Whiteboard: [closeme 2010-03-03] → [add-on]
so sorry for not really following up here. Problem is that it was mostly me on amd64 and on i386 mem consumption was ok.

This seems to happen only if you have HUGE folders (e.g. >200k mails).

anyway, i didnt get explicit complains about this after releasing to ubuntu/lucid. Most negative feedback was about indexer spinning forever for folks migrating from tbird 2 setups (e.g. all gets downloaded and indexed).
... and no ... it definitly wasnt enigmail, as enigmail was not available for tbird3 until a few days ago for ubuntu
You need to log in before you can comment on or make changes to this bug.