Closed Bug 263109 Opened 21 years ago Closed 18 years ago

Hang(?) if I try opening an mbox file from Mutt

Categories

(Thunderbird :: Mail Window Front End, defect)

Product:
Thunderbird
Component:
Mail Window Front End
Platform:
PowerPC
macOS
Type:
defect
Priority:
Not set
Severity:
normal

Tracking

(Not tracked)

Status:
RESOLVED INCOMPLETE

People

(Reporter: gharris, Assigned: mscott)

Details

(Whiteboard: closeme 2008-08-28)

Attachments

(1 file)

Sample mailbox I used when reproducing the bug
2.54 KB, application/octet-stream
Details
User-Agent: Mozilla/5.0 (Macintosh; U; PPC Mac OS X; en) AppleWebKit/125.5 (KHTML, like Gecko) Safari/125.9 Build Identifier: version 0.8 (20040913) I moved from Mutt to Thunderbird. I had a number of mbox files, and directories with other mbox files, and moved those over to ~/Library/Thunderbird/Profiles/default.vwv/Mail/pop.sonic.net. The mailboxes do show up in the Folders sidebar. However, for at least some of them, if I click on the mailbox I get an hourglass cursor - which, for one large mailbox (1104897 bytes), didn't go away after about 6 hours of continuous running on my 1.5 GHz/1GB PowerBook running OS X 10.3.5. For a smaller mailbox (2027 bytes), it didn't finish after several minutes. The UI isn't frozen; I can go to other mailboxes, for example, and it works fine, and can exit Thunderbird. Reproducible: Always Steps to Reproduce: 1. When Thunderbird isn't running, copy the attached mailbox (I'm assuming I can attach files to Bugzilla bugs; if not, I'll add it some other way) to a subdirectory of your mail directory (e.g., to ~/ Library/Thunderbird/Profiles/default.vwv/Mail/{your POP server's domain name}/test), creating such a subdirectory if it doesn't exist. 2. Start Thunderbird. 3. Click on the copied mailbox. Actual Results: I got an hourglass cursor, and the mailbox wasn't open. Expected Results: Open the mailbox (presumably creating a .msf file if necessary).
With 0.9, it still hangs - but, if I rename the directory in question to something else, create a new folder with the name I want for that folder, and then rename the directory to {name}.sbd, I can open the subfolders of that folder without a hang. I'm not sure what the right thing to do with a directory whose name doesn't end with ".sbd" is, but hanging if you try to open a file in that directory isn't it; either it should refuse to recognize subdirectories that don't have ".sbd", or should treat them just as subdirectories with ".sbd" are treated (but that makes it difficult to put messages into the folder rather than subfolders, so that's probably wrong), or it should warn you when building the sidebar with the folder list that there's a directory named xxx that should be named xxx.sbd instead and, if the user says "OK", rename the directory to xxx.sbd and create, if necessary, an empty xxx file and an xxx.msf file, or....
This is an automated message, with ID "auto-resolve01". This bug has had no comments for a long time. Statistically, we have found that bug reports that have not been confirmed by a second user after three months are highly unlikely to be the source of a fix to the code. While your input is very important to us, our resources are limited and so we are asking for your help in focussing our efforts. If you can still reproduce this problem in the latest version of the product (see below for how to obtain a copy) or, for feature requests, if it's not present in the latest version and you still believe we should implement it, please visit the URL of this bug (given at the top of this mail) and add a comment to that effect, giving more reproduction information if you have it. If it is not a problem any longer, you need take no action. If this bug is not changed in any way in the next two weeks, it will be automatically resolved. Thank you for your help in this matter. The latest beta releases can be obtained from: Firefox: http://www.mozilla.org/projects/firefox/ Thunderbird: http://www.mozilla.org/products/thunderbird/releases/1.5beta1.html Seamonkey: http://www.mozilla.org/projects/seamonkey/
This bug has been automatically resolved after a period of inactivity (see above comment). If anyone thinks this is incorrect, they should feel free to reopen it.
Status: UNCONFIRMED → RESOLVED
Closed: 20 years ago
Resolution: --- → EXPIRED
It still happens with 1.5 RC1 (version 1.5 (20051025)) on OS X 10.4.3. Here's the result of running "sample thunderbird-bin 5" while it was spinning. It wasn't *completely* hung - I could still quit from the menu - but it never opened the mailbox. Analysis of sampling pid 4294 every 10.000000 milliseconds Call graph: 461 Thread_0f0f 461 start 461 start 461 XRE_main 461 nsAppStartup::Run() 461 nsAppShell::Run() 461 nsMacMessagePump::DoMessagePump() 460 nsMacMessagePump::GetEvent(EventRecord&) 460 WaitNextEvent 460 WNEInternal 460 GetNextEventMatchingMask 460 RunCurrentEventLoopInMode 460 CFRunLoopRunSpecific 459 __CFRunLoopRun 458 mach_msg 458 mach_msg_trap 458 mach_msg_trap 1 mk_timer_destroy 1 mk_timer_destroy 1 __CFRunLoopDoObservers 1 FlushAllWindows() 1 FlushWindowObject(WindowData*, void**, unsigned char) 1 QDFlushPortBuffer 1 QDPlatformFlushWindow 1 _CGSWindowByID 1 _CGSWindowByID 1 nsMacMessagePump::DispatchEvent(int, EventRecord*) 1 PR_Sleep 1 sched_yield 1 swtch_pri 1 swtch_pri 461 Thread_1003 461 _pthread_body 461 PR_Select 461 nsThread::Main(void*) 461 nsSocketTransportService::Run() 461 nsSocketTransportService::Poll(unsigned*) 461 PR_OpenDir 461 poll 461 select 461 select 461 Thread_1103 461 _pthread_body 461 PR_Select 461 nsThread::Main(void*) 461 TimerThread::Run() 461 PR_WaitCondVar 461 PR_Unlock 461 pthread_cond_timedwait 461 semaphore_timedwait_signal_trap 461 semaphore_timedwait_signal_trap 461 Thread_1203 461 _pthread_body 461 PR_Select 461 nsIOThreadPool::ThreadFunc(void*) 461 PR_WaitCondVar 461 PR_Unlock 461 pthread_cond_timedwait 461 semaphore_timedwait_signal_trap 461 semaphore_timedwait_signal_trap 461 Thread_1303 461 _pthread_body 461 PR_Select 461 nsHostResolver::ThreadFunc(void*) 461 nsHostResolver::GetHostToLookup(nsHostRecord**) 461 PR_WaitCondVar 461 PR_Unlock 461 pthread_cond_timedwait 461 semaphore_timedwait_signal_trap 461 semaphore_timedwait_signal_trap 461 Thread_1403 461 _pthread_body 461 PR_Select 461 nsIOThreadPool::ThreadFunc(void*) 461 PR_WaitCondVar 461 PR_Unlock 461 pthread_cond_timedwait 461 semaphore_timedwait_signal_trap 461 semaphore_timedwait_signal_trap 461 Thread_1503 461 _pthread_body 461 PR_Select 461 nsIOThreadPool::ThreadFunc(void*) 461 PR_WaitCondVar 461 PR_Unlock 461 pthread_cond_timedwait 461 semaphore_timedwait_signal_trap 461 semaphore_timedwait_signal_trap 461 Thread_1603 461 _pthread_body 461 PR_Select 461 nsIOThreadPool::ThreadFunc(void*) 461 PR_WaitCondVar 461 PR_Unlock 461 pthread_cond_timedwait 461 semaphore_timedwait_signal_trap 461 semaphore_timedwait_signal_trap Total number in stack (recursive counted multiple, when >=5): 7 PR_Select 7 _pthread_body 6 PR_Unlock 6 PR_WaitCondVar 6 pthread_cond_timedwait 6 semaphore_timedwait_signal_trap Sort by top of stack, same collapsed (when >= 5): semaphore_timedwait_signal_trap 2766 select 461 mach_msg_trap 458
Status: RESOLVED → UNCONFIRMED
Resolution: EXPIRED → ---
Version: unspecified → 1.5
QA Contact: front-end
Reporter, does the issue still occur with the latest supported 2.0.0.x / Shredder trunk nightlies? (1.5.0.x is now end-of-life and the latest supported Thunderbird version 2 is 2.0.0.16)
Whiteboard: closeme 2008-08-28
Beats me. I haven't run Thunderbird in a while; it appeared to hang when I tried starting it after a Leopard upgrade, and I switched to OS X's Mail app (which I'd been planning to do for a while). Feel free to close it.
Resolving incomplete due to lack of information as per comment #7. Running Thunderbird 2 / 3 in Leopard works as expected.
Status: UNCONFIRMED → RESOLVED
Closed: 20 years ago → 18 years ago
Resolution: --- → INCOMPLETE
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: