matteo sisti sette Reporter
	Description • 12 years ago

User Agent: Mozilla/5.0 (X11; Linux i686) AppleWebKit/537.22 (KHTML, like Gecko) Chrome/25.0.1364.97 Safari/537.22

Steps to reproduce:

- Select a folder that contains many hundreds thousands messages
- Click on one message
- Shift+Click on another message many thousands of messages below. I.e., selecting many messages


Actual results:

Huge CPU usage started, TB hanged, eventually crashed, and now I cannot start TB any more.
Whenever I try to start TB I get the error: 
"Your Thunderbird profile cannot be loaded. It may be missing or inaccessible."

ALL MY DATA GOT DESTROYED. (or anyway made completely unaccessible.


Expected results:

Nothing. Just the message should have been selected, which should take a fraction of a second, and no operation should have been done.

FOR GOD'S SAKE IS THERE A WAY I CAN RECOVER MY DATA?

	matteo sisti sette Reporter
	Comment 1 • 12 years ago

Oh ****, is P1 or P5 the topmost priority? When are you going to upgrade to the version of bugzilla that has that fixed?

	matteo sisti sette Reporter
	Comment 2 • 12 years ago

Wow, fortunately (and surprisingly), the profile corruption got fixed after a reboot. As crazy as it sounds. After reboot, TB works normally.

The bug is still valid though.
I don't think this is a duplicate of 583365, since I didn't trigger any action with the selected messages. It was just the mere fact of selecting them that triggered the hanging and crash (and subsequent inability to launch TB until reboot).

	Wayne Mery (:wsmwk)
	Comment 3 • 12 years ago

(except for the aftereffects of your crash) I don't see why this would not be a duplicate of bug 583365.

And the likely crash signature is bug 610551.  But it best if you could tell us your stack - did thunderbird produce a crash report? What distro of linux do you run?

I can appreciate your shock of having potentially lost your profile. But unless you developing code for thunderbird please do not abuse priority by setting blocking. Please see the definition at https://bugzilla.mozilla.org/page.cgi?id=fields.html#bug_severity

	matteo sisti sette Reporter
	Comment 4 • 12 years ago

It _may_ be a dup of 583365 but I see a huge difference:
- in my case the hanging, huge cpu consumption and crash happened at the very moment of selecting the messages, before I even planned to do anything with them.
- 583365's OP says he could select all the messages and then click the Archive button, and that a few messages were actually moved before the crash. Looks like in that case it was the actual moving of files that produce the memory explosion (and it's not clear whether there was big cpu load)

The underlying issue may be the same but the behavior described seems to me very different.

If you are sure both come from the same underlying issue feel free to mark it as duplicate.

	:aceman
	Comment 5 • 12 years ago

If this is connected with the building of the summary pane, then bug 778907 may help this. However, only when you disable it. So for the non-disabled case, we could add some sanity checking, e.g. do not summarize more than 1000 messages.

matteo, can you see how much memory TB takes when this happens? Can you see if it crashes because of memory exhaustion (taking all memory+swap or reaching 3GB/4GB of RAM)?

	Wayne Mery (:wsmwk)
	Comment 6 • 11 years ago

(In reply to :aceman from comment #5)
> matteo, can you see how much memory TB takes when this happens? Can you see
> if it crashes because of memory exhaustion (taking all memory+swap or
> reaching 3GB/4GB of RAM)?

	matteo sisti sette Reporter
	Comment 7 • 11 years ago

Sorry but I'm not going to provoke a TB crash for the sake of testing this. I got enough scared when I thought I lost all my profile data until reboot, and I'm not going to _assume_ data corruption won't happen because it didn't happen the first time.

However, the apparent profile corruption that I experienced in that occasion (when the profile became apparently corrupt or inaccessible until reboot) may have been due to a bug in Linux where the ntfs filesystem driver/whateveritscalled often crashes, usually in coincidence with massive read/writes, so that may have been the case, triggered maybe by TB's massive read operations. (I have my profile in a ntfs partition). In that occasion I didn't realise it.

That may even be what caused TB's crash. So this may in the end be a dupe of Bug #778907.

	Wayne Mery (:wsmwk)
	Comment 8 • 11 years ago

Then let's assume dupe, A. selection is highly unlikely to have caused B. dataloss