119521 - A crash occurs when typing a new URL address as a ftp process is occuring

Status: RESOLVED WORKSFORME

(Core :: XPCOM, defect)

Description

[Chris Petersen]

Build: 2002-01-11-08
Platform: OS X
Expected Results: Typing a new url address ( during a ftp process) should cause
the application to crash.
What I got: As I'm typing a new url in the field, the application suddenly crashes.

Steps to reproduce:

1) Go to
http://ftp.mozilla.org/pub/mozilla/nightly/latest/mozilla-macosX-trunk.smi.bin

2) In Download dialog, click either Stuff Expander or Save to Disk. Click OK.
 Save file dialog opens and the ftp process begins.

3) Bring the browser window to front by clicking on it.


4) Delete the contents of the url field and start to type a new address.


5) The crash should occur while typing.

Comment 1

[Chris Petersen]

Here's the stack trace from my Dual G4 (800 mhz)

**********

Date/Time:  2002-01-11 12:03:12 -0800
OS Version: 10.1.2 (Build 5P48)

Command:    Netscape 6
PID:        806

Exception:  EXC_BAD_ACCESS (0x0001)
Codes:      KERN_PROTECTION_FAILURE (0x0002) at 0x00000000

Thread 0:
 #0   0x0062a640 in nsTimerImpl::Fire(void)
 #1   0x0062a634 in nsTimerImpl::Fire(void)
 #2   0x006296fc in TimerThread::Run(void)
 #3   0x005bb018 in nsThread::Main(void *)
 #4   0x0050909c in 0x50909c

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: 0x0062a640 srr1: 0x0000f030                vrsave: 0x00000000
   xer: 0x00000014   lr: 0x0062a634  ctr: 0x700056fc   mq: 0x00000000
    r0: 0x0062a634   r1: 0x02398c60   r2: 0x00104000   r3: 0x00000000
    r4: 0x05752d00   r5: 0x0010bc78   r6: 0x01bc24c0   r7: 0x01bc2490
    r8: 0x0004c2a4   r9: 0x80240e10  r10: 0x00000024  r11: 0x80003710
   r12: 0x700056fc  r13: 0x00000000  r14: 0x00000036  r15: 0x00075bd0
   r16: 0x00075c00  r17: 0xbfffee90  r18: 0x00531ec0  r19: 0x00003b07
   r20: 0x00000000  r21: 0x0000001c  r22: 0x70004234  r23: 0x700042c8
   r24: 0x00000004  r25: 0x000003a4  r26: 0x70002d84  r27: 0x70002e10
   r28: 0x00000000  r29: 0xbfffef00  r30: 0x00000000  r31: 0x00000001

**********

Comment 2

[Simon Fraser [no longer active]]

This is timer stuff. Stuart?

Comment 3

[Olav Vitters]

This should be marked WONTFIX. If the reporter expects Mozilla to crash, fixing
the bug will lead to confusion.

Comment 4

[Chris Petersen]

Oops.... 
Expected Results: Typing a new url address ( during a ftp process) SHOULDN'T
cause the application to crash.

Comment 5

[Matthias Versen [:Matti]]

*** Bug 119785 has been marked as a duplicate of this bug. ***

Comment 6

[Mike Pinkerton (not reading bugmail)]

d00d, you don't future crashing bugs.

Comment 7

[Simon Fraser [no longer active]]

I think this was probably fixed by the MPSemaphore changes in NSPR. It needs re-
testing.

Comment 8

[Chris Petersen]

With the Feb 6th build (2002-02-06-03), I can nolonger reproduce this crash.
Tested under OS X 10.1.2 on a Dual G4 800.

Comment 9

[scattol]

This doesn't look like it's fixed.

I got this exact same problem when typing an URL in the textfield of the browser
with regular HTTP session on a Win2K box Athlon single processor with build
2002021108

Talkback number TB2796562K

Comment 10

[Stuart Parmenter]

scattol: according to your talkback report, your stack was:
js_AllocGCThing [d:\builds\seamonkey\mozilla\js\src\jsgc.c, line 528] 
js_NewObject [d:\builds\seamonkey\mozilla\js\src\jsobj.c, line 1613] 
0x35411600 
I don't believe this is at related.

Marking worksforme based on testing from QA.