Closed Bug 119448 Opened 24 years ago Closed 23 years ago

Crash on timer thread

Categories

(MailNews Core :: Networking: IMAP, defect)

Product:
MailNews Core
Component:
Networking: IMAP
Platform:
PowerPC
macOS
Type:
defect
Priority:
Not set
Severity:
critical

Tracking

(Not tracked)

Status:
RESOLVED WORKSFORME

People

(Reporter: pekka.nikander, Assigned: mscott)

Details

(Keywords: crash)

Fizzilla 2001122809 In the middle of heavy use, i.e. reading mail, opening web pages, etc. I got the following crash on the Timer thread. Date/Time: 2002-01-11 13:22:41 +0200 OS Version: 10.1.2 (Build 5P48) Command: Mozilla PID: 5575 Exception: EXC_BAD_ACCESS (0x0001) Codes: KERN_PROTECTION_FAILURE (0x0002) at 0x00000000 Thread 0: #0 0x0062805c in nsTimerImpl::Fire(void) #1 0x00628050 in nsTimerImpl::Fire(void) #2 0x0062716c in TimerThread::Run(void) #3 0x005b8278 in nsThread::Main(void *) #4 0x0050609c in 0x50609c Thread 1: #0 0x7000497c in syscall #1 0x70557600 in BSD_waitevent #2 0x70554b80 in CarbonSelectThreadFunc #3 0x7002054c in _pthread_body Thread 2: #0 0x7003f4c8 in semaphore_wait_signal_trap #1 0x7003f2c8 in _pthread_cond_wait #2 0x705593ec in CarbonOperationThreadFunc #3 0x7002054c in _pthread_body Thread 3: #0 0x70044cf8 in semaphore_timedwait_signal_trap #1 0x70044cd8 in semaphore_timedwait_signal #2 0x7003f2b8 in _pthread_cond_wait #3 0x70283ea4 in TSWaitOnConditionTimedRelative #4 0x7027d748 in TSWaitOnSemaphoreCommon #5 0x702c2078 in TimerThread #6 0x7002054c in _pthread_body Thread 4: #0 0x7003f4c8 in semaphore_wait_signal_trap #1 0x7003f2c8 in _pthread_cond_wait #2 0x70250ab0 in TSWaitOnCondition #3 0x7027d730 in TSWaitOnSemaphoreCommon #4 0x70243d14 in AsyncFileThread #5 0x7002054c in _pthread_body Thread 5: #0 0x7003f4c8 in semaphore_wait_signal_trap #1 0x7003f2c8 in _pthread_cond_wait #2 0x7055b884 in CarbonInetOperThreadFunc #3 0x7002054c in _pthread_body Thread 6: #0 0x70000978 in mach_msg_overwrite_trap #1 0x70005a04 in mach_msg #2 0x7017bf98 in __CFRunLoopRun #3 0x701b7100 in CFRunLoopRunSpecific #4 0x7017b8e0 in CFRunLoopRunInMode #5 0x7061be08 in XIOAudioDeviceManager::NotificationThread(XIOAudioDeviceManager *) #6 0x706141c0 in CAPThread::Entry(CAPThread *) #7 0x7002054c in _pthread_body Thread 7: #0 0x70000978 in mach_msg_overwrite_trap #1 0x70005a04 in mach_msg #2 0x70026a2c in _pthread_become_available #3 0x70026724 in pthread_exit #4 0x70020550 in _pthread_body PPC Thread State: srr0: 0x0062805c srr1: 0x0000f030 vrsave: 0x00000000 xer: 0x00000004 lr: 0x00628050 ctr: 0x700056fc mq: 0x00000000 r0: 0x00628050 r1: 0x02ad4c60 r2: 0x00101000 r3: 0x00000000 r4: 0x05f26760 r5: 0x00108d00 r6: 0x02a91fe0 r7: 0x00000000 r8: 0x0004f8c4 r9: 0x80240e10 r10: 0x00000024 r11: 0x80003710 r12: 0x700056fc r13: 0x00000000 r14: 0x00000036 r15: 0x00060ee0 r16: 0x00000001 r17: 0x80160fa8 r18: 0x0005cf28 r19: 0x00001a07 r20: 0x00000000 r21: 0x0000001c r22: 0x70004234 r23: 0x700042c8 r24: 0x7016b0dc r25: 0x006bac3c r26: 0x8081ab5c r27: 0x40bc2000 r28: 0x00000000 r29: 0xbfffef00 r30: 0x52410000 r31: 0x00000001 **********
Severity: major → critical
Keywords: crash
I am still using 2001122809 (20020216 is unuseable), and got another of these timer crashes today (see below). My gut feeling is that something bad is happening with my IMAP accounts. I have three IMAP accounts, and mozilla is checking mail from them periodically. Maybe sometimes something bad happens with one of these, and the timer thread crashes. Or maybe not. Anyhow, I seem to get these timer thread crashes every now and then, at least with this particular build. I'll try a newer build once I find one that is useable. Date/Time: 2002-01-17 15:45:20 +0200 OS Version: 10.1.2 (Build 5P48) Command: Mozilla PID: 21595 Exception: EXC_BAD_ACCESS (0x0001) Codes: KERN_PROTECTION_FAILURE (0x0002) at 0x00000000 Thread 0: #0 0x0062805c in nsTimerImpl::Fire(void) #1 0x00628050 in nsTimerImpl::Fire(void) #2 0x0062716c in TimerThread::Run(void) #3 0x005b8278 in nsThread::Main(void *) #4 0x0050609c in 0x50609c Thread 1: #0 0x7000497c in syscall #1 0x70557600 in BSD_waitevent #2 0x70554b80 in CarbonSelectThreadFunc #3 0x7002054c in _pthread_body Thread 2: #0 0x7003f4c8 in semaphore_wait_signal_trap #1 0x7003f2c8 in _pthread_cond_wait #2 0x705593ec in CarbonOperationThreadFunc #3 0x7002054c in _pthread_body Thread 3: #0 0x70044cf8 in semaphore_timedwait_signal_trap #1 0x70044cd8 in semaphore_timedwait_signal #2 0x7003f2b8 in _pthread_cond_wait #3 0x70283ea4 in TSWaitOnConditionTimedRelative #4 0x7027d748 in TSWaitOnSemaphoreCommon #5 0x702c2078 in TimerThread #6 0x7002054c in _pthread_body Thread 4: #0 0x7003f4c8 in semaphore_wait_signal_trap #1 0x7003f2c8 in _pthread_cond_wait #2 0x70250ab0 in TSWaitOnCondition #3 0x7027d730 in TSWaitOnSemaphoreCommon #4 0x70243d14 in AsyncFileThread #5 0x7002054c in _pthread_body Thread 5: #0 0x7003f4c8 in semaphore_wait_signal_trap #1 0x7003f2c8 in _pthread_cond_wait #2 0x7055b884 in CarbonInetOperThreadFunc #3 0x7002054c in _pthread_body Thread 6: #0 0x70000978 in mach_msg_overwrite_trap #1 0x70005a04 in mach_msg #2 0x7017bf98 in __CFRunLoopRun #3 0x701b7100 in CFRunLoopRunSpecific #4 0x7017b8e0 in CFRunLoopRunInMode #5 0x7061be08 in XIOAudioDeviceManager::NotificationThread(XIOAudioDeviceManager *) #6 0x706141c0 in CAPThread::Entry(CAPThread *) #7 0x7002054c in _pthread_body Thread 7: #0 0x70044cf8 in semaphore_timedwait_signal_trap #1 0x70044cd8 in semaphore_timedwait_signal #2 0x7003f2b8 in _pthread_cond_wait #3 0x70283ea4 in TSWaitOnConditionTimedRelative #4 0x70270138 in MPWaitOnQueue #5 0x70777cd8 in TNodeSyncTask::SyncTaskProc(void *) #6 0x702831a8 in PrivateMPEntryPoint #7 0x7002054c in _pthread_body Thread 8: #0 0x70000978 in mach_msg_overwrite_trap #1 0x70005a04 in mach_msg #2 0x70026a2c in _pthread_become_available #3 0x70026724 in pthread_exit #4 0x70020550 in _pthread_body PPC Thread State: srr0: 0x0062805c srr1: 0x0000f030 vrsave: 0x00000000 xer: 0x00000004 lr: 0x00628050 ctr: 0x700056fc mq: 0x00000000 r0: 0x00628050 r1: 0x02ad7c60 r2: 0x00101000 r3: 0x00000000 r4: 0x06f7c1f0 r5: 0x00108d00 r6: 0x02242680 r7: 0x00000000 r8: 0x0004f8c4 r9: 0x80240e10 r10: 0x00000024 r11: 0x80003710 r12: 0x700056fc r13: 0x00000000 r14: 0x00000036 r15: 0x00653a20 r16: 0x00653a20 r17: 0xbfffee90 r18: 0x000638c8 r19: 0x00003707 r20: 0x00000000 r21: 0x0000001c r22: 0x70004234 r23: 0x700042c8 r24: 0x00000004 r25: 0x000006eb r26: 0x8081ab5c r27: 0x0005f9d0 r28: 0x00000000 r29: 0xbfffef00 r30: 0x00000000 r31: 0x00000001 **********
Reporter If you think this is related to Imap accounts please change product to mailnews and component to IMAP (don't have the name handy ....).
Changing to MailNews and IMAP based on my gut feeling, as suggested by Ludovic Hirlimann. However, this *may* be a wrong guess about what is happening. Anyway, the only background activity that I am _aware_ of is checking the IMAP accounts.
Component: Browser-General → Networking - IMAP
Product: Browser → MailNews
cc'ing my favorite timer culprits. and reassigning based on reporter's guess.
Assignee: asa → mscott
QA Contact: doronr → huang
I've seen this with quick search on multi processor win2k machines. the crash for that looks like this: nsTimerImpl::Fire() line 374 + 21 bytes TimerThread::Run(TimerThread * const 0x015a7350) line 213 nsThread::Main(void * 0x015a7640) line 120 + 26 bytes _PR_NativeRunThread(void * 0x015a7760) line 413 + 13 bytes _threadstartex(void * 0x015a7a08) line 212 + 13 bytes KERNEL32! 77e8758a() mCallingThread (and bunch of other member variables) look bad. they're all set to 0xfeeefeee confirming, for now. reporter, were you doing quick search? or, do you have a multi processor box?
Status: UNCONFIRMED → NEW
Ever confirmed: true
> reporter, were you doing quick search? or, do you have a multi processor box? Unfortunately I don't remember any more if I was doing quick searches or not. It was more like I got timer thread crashes a few times with a few particular versions of MacOS X trunk build, and I haven't seen them since I moved to newer versions, i.e. ones build in February or newer. It is also possible that my mail settings have changed sufficiently so that I don't see these crashes any more. I don't have a multi prosessor box.
Is this still happening? There have been some fixes to the timer code since the last comment in this bug.
This is not happening (to me) any more.
marking wfm now - probably fixed a while ago.
Status: NEW → RESOLVED
Closed: 23 years ago
Resolution: --- → WORKSFORME
QA Contact: huang → gchan
Product: MailNews → Core
Product: Core → MailNews Core
You need to log in before you can comment on or make changes to this bug.