Build: 2001-10-22-18 Platform: Mac OSX Expected Results: Query submission should be completed with no crash. What I got: During the second query, I received a crash. ********** Date/Time: 2001-10-23 10:53:38 -0700 OS Version: 10.1 (Build 5L14) Command: Netscape 6 PID: 316 Exception: EXC_BAD_ACCESS (0x0001) Codes: KERN_INVALID_ADDRESS (0x0001) at 0x045ff58c Thread 0: #0 0x021e17bc in nsMacMemoryCushion::RecoverMemoryReserve(long) #1 0xbffff68c in 0xbffff68c #2 0x021e1724 in nsMacMemoryCushion::RepeatAction(EventRecord const &) #3 0x022095ac in Repeater::DoRepeaters(EventRecord const &) #4 0x021f4fbc in nsMacMessagePump::DispatchEvent(int, EventRecord *) #5 0x021f4b88 in nsMacMessagePump::DoMessagePump(void) #6 0x021f4418 in nsAppShell::Run(void) #7 0x01ea4374 in nsAppShellService::Run(void) #8 0x004bb39c in main1(int, char **, nsISupports *) #9 0x004bc078 in main Thread 1: #0 0x7000530c in syscall #1 0x70557590 in BSD_waitevent #2 0x70554a30 in CarbonSelectThreadFunc #3 0x70020efc in _pthread_body Thread 2: #0 0x7003fe48 in semaphore_wait_signal_trap #1 0x7003fc48 in _pthread_cond_wait #2 0x705594ac in CarbonOperationThreadFunc #3 0x70020efc in _pthread_body Thread 3: #0 0x70043988 in semaphore_timedwait_signal_trap #1 0x70043968 in semaphore_timedwait_signal #2 0x7003fc38 in _pthread_cond_wait #3 0x7028366c in TSWaitOnConditionTimedRelative #4 0x7027cf10 in TSWaitOnSemaphoreCommon #5 0x702c14c8 in TimerThread #6 0x70020efc in _pthread_body Thread 4: #0 0x7003fe48 in semaphore_wait_signal_trap #1 0x7003fc48 in _pthread_cond_wait #2 0x702505cc in TSWaitOnCondition #3 0x7027cef8 in TSWaitOnSemaphoreCommon #4 0x7024386c in AsyncFileThread #5 0x70020efc in _pthread_body Thread 5: #0 0x7003fe48 in semaphore_wait_signal_trap #1 0x7003fc48 in _pthread_cond_wait #2 0x7055b9b4 in CarbonInetOperThreadFunc #3 0x70020efc in _pthread_body PPC Thread State: srr0: 0x021e17bc srr1: 0x0000f030 vrsave: 0x00000000 xer: 0x0000001c lr: 0x021e1724 ctr: 0x021e170c mq: 0x00000000 r0: 0x021e1724 r1: 0xbffff1b0 r2: 0x0226b000 r3: 0x045ff58c r4: 0x00008000 r5: 0x00000000 r6: 0x00000000 r7: 0x00000000 r8: 0x834da65c r9: 0x834e058c r10: 0x0332b092 r11: 0x00000000 r12: 0x02263f88 r13: 0x00000000 r14: 0x00000033 r15: 0xbfffee58 r16: 0xbfffee70 r17: 0x00000001 r18: 0x000585b8 r19: 0x0000140b r20: 0x00000000 r21: 0x0000001c r22: 0x70004bc4 r23: 0x70004c58 r24: 0x00000001 r25: 0x000006eb r26: 0x8081ab5c r27: 0x00063cf0 r28: 0x00000000 r29: 0xbfffef00 r30: 0x8081d1cc r31: 0x00000001 **********

Steps to reproduce: 1) Go to http://bugzilla.mozilla.org/query.cgi 2) Select Resolved /Fixed , select Mac OS X for Platform, type petersen as reporter. 3) Click the submit query button. 4) After query is finished, press the back arrow on toolbar. 5) Select QA content instead of Reporter 6) Click the submit query button again. 7) During the process of this second query, I have recieved a crash.

-> pinkerton/sfraser (petersen: is it the same stack info as above each time you crash?)

nsMacMemoryCushion is simon's.

Yes, the stack trace is same on both crashes I recieved.

Something is trashing the heap. I bet it's not me.

does this also happen on os9? can you pin down a day in which this started happening? if it's heap corruption, that might be tough to track down on X.

does this occur with trunk builds? looking at the buildid, this occurred in the branch... just wondering.

I can do some more research on this issue. I haven't try this under OS 9 yet so I'm not sure if it occurs. I haven't been able to reproduce under OS X 10.0.4 from my steps. However, this occured twice with today's build and once on yesterday's build under OS X 10.1.

This problem seems to occur only with OS X branch build. I tried the Oct 22 OS X trunk and couldn't reproduce it. Nor would this problem occur under Windows or Linux branch builds either.

Doesn't occur under the Mac OS 9.1 branch either. Let's try with a new profile under OS X to see if it still reproduces.

The problem still occurs with a new user profile. Modern skin is active. Try these steps to consistantly reproduce: 1) Go to http://bugzilla.mozilla.org/query.cgi 2)In the second mail field, type in petersen (leave all default setting alone on this page) 3) Scroll down and click on "Submit Query" 4) After query is completed and page is displayed, click the back arrow on toolbar 5) Change the following on the page: Set Status to resolved Set Resolution to fixed Uncheck Reporter and select QA contact 6)Scroll down and click on "Submit Query" 7) Query begins but app crashes

adding crash and regression keyword.

I cannot reproduce this following your steps, Chris. I have OS 10.1. When you created a new profile, do you activate any accounts? I'm wondering if it's steps which you are doing leading up to a crash.

No, I go directly to mozilla and start the query.

The key to reproducing this problem is to have the "Unencrypted page to an unencrypted page" turned on. This option should be on by default..

I can't reproduce with OS 9 branch build (2001-10-22-17) with "Unencrypted" option on. Seems to be only under 10.1.

This query problem (using the steps provided) reproduces on two different Mac : iBook (500 mhz) and PowerMac G4-450. On a third Mac (G3 266), the crash doesn't after the second query. If you press the back toolbar arrow to return to Bugzilla query page , pressing Command -Q will cause the application while quitting.

Stack trace from (G3/ 266). This crash didn't occur after the second query but happened when quitting the application (Command- Q) ********** Date/Time: 2001-10-25 16:36:04 -0700 OS Version: 10.1 (Build 5G64) Command: Netscape 6 PID: 251 Exception: EXC_BAD_ACCESS (0x0001) Codes: KERN_INVALID_ADDRESS (0x0001) at 0x03eac60c Thread 0: #0 0x7024e80c in DisposeHandle #1 0x01d5b5cc in _dt__18nsMacMemoryCushionFv #2 0x01d6e6cc in _dt__10nsAppShellFv #3 0x01d6dfc0 in Release__10nsAppShellFv #4 0x00573460 in _dt__13nsCOMPtr_baseFv #5 0x01a2194c in _dt__17nsAppShellServiceFv #6 0x01a21a5c in Release__17nsAppShellServiceFv #7 0x0056ee94 in DeleteEntry__FP9nsHashKeyPvPv #8 0x00566fc8 in hashEnumerateRemove__FP11PLHashEntryiPv #9 0x004dc1c0 in 0x4dc1c0 #10 0x005670c4 in Reset__11nsHashtableFPFP9nsHashKeyPvPv_iPv #11 0x00568b10 in Reset__17nsObjectHashtableFv #12 0x00568928 in _dt__17nsObjectHashtableFv #13 0x0056f014 in _dt__20nsServiceManagerImplFv #14 0x0056f120 in Release__20nsServiceManagerImplFv #15 0x00570090 in ShutdownGlobalServiceManager__16nsServiceManagerFPP17nsIServic #16 0x005b153c in NS_ShutdownXPCOM__FP17nsIServiceManager #17 0x004bc090 in main Thread 1: #0 0x7000530c in syscall #1 0x70557590 in BSD_waitevent #2 0x70554a30 in CarbonSelectThreadFunc #3 0x70020efc in _pthread_body Thread 2: #0 0x7003fe48 in semaphore_wait_signal_trap #1 0x7003fc48 in _pthread_cond_wait #2 0x705594ac in CarbonOperationThreadFunc #3 0x70020efc in _pthread_body Thread 3: #0 0x70043988 in semaphore_timedwait_signal_trap #1 0x70043968 in semaphore_timedwait_signal #2 0x7003fc38 in _pthread_cond_wait #3 0x7028366c in TSWaitOnConditionTimedRelative #4 0x7027cf10 in TSWaitOnSemaphoreCommon #5 0x702c14c8 in TimerThread #6 0x70020efc in _pthread_body Thread 4: #0 0x7003fe48 in semaphore_wait_signal_trap #1 0x7003fc48 in _pthread_cond_wait #2 0x702505cc in TSWaitOnCondition #3 0x7027cef8 in TSWaitOnSemaphoreCommon #4 0x7024386c in AsyncFileThread #5 0x70020efc in _pthread_body Thread 5: #0 0x7003fe48 in semaphore_wait_signal_trap #1 0x7003fc48 in _pthread_cond_wait #2 0x7055b9b4 in CarbonInetOperThreadFunc #3 0x70020efc in _pthread_body PPC Thread State: srr0: 0x7024e80c srr1: 0x0000f030 vrsave: 0x00000000 xer: 0x00000008 lr: 0x7024e7ec ctr: 0x7024e7d8 mq: 0x00000000 r0: 0x01d5b5cc r1: 0xbffff0f0 r2: 0x702c0f58 r3: 0x03eac60c r4: 0x00000001 r5: 0x0000000a r6: 0x01b38eff r7: 0x00000000 r8: 0x00000000 r9: 0x8024509c r10: 0x03c43010 r11: 0x800033fc r12: 0x802429a0 r13: 0x00000000 r14: 0x00000033 r15: 0xbfffee58 r16: 0xbfffee70 r17: 0x00000001 r18: 0x000585b8 r19: 0x00001007 r20: 0x00000000 r21: 0x0000001c r22: 0x70004bc4 r23: 0x70004c58 r24: 0x00000001 r25: 0x000006eb r26: 0x8081ab5c r27: 0x0005f540 r28: 0x00000000 r29: 0xbfffef00 r30: 0x8081d1cc r31: 0x00000001 **********

Chris: can you still reproduce this? Note also bugs 98359, 114907 and 115698 have similar stack traces.

Hmmm... I can't reproduce the crash with any of the steps I provided using the Jan 30th build (2002-01-30-03). This was a very reproducable and consistant bug for me. Ran into this issue on a frequent basis.... Tested under OS X 10.1.2.

This will be bug 124517. *** This bug has been marked as a duplicate of 124517 ***