109645 - Crash loading page

Status: VERIFIED FIXED

(SeaMonkey :: UI Design, defect)

Description

[James Green]

Visit the url and click the 800x600 link on any of the backgrounds.

CPU goes up to 100% for a short while, then a new window opens, and finally the
browser crashes.

Appears to occur on any wallpaper list page.

Comment 1

[James Green]

Looking for someone with a debug build to get a backtrace so we can send to the
right component.

Comment 2

[R.K.Aa.]

wfm 2001110806 linux. Which build are you testing with?

Comment 3

[Robert Ginda]

I didn't crash right away in gdb, instead it waited until I closed the window. 
I'll attach a stack trace.

Comment 4

[Robert Ginda]

Attachment: stack trace of crash after closing the window

If I run outside of gdb, I crash when the window opens.  With gdb, crash when
the window is closed.  Go figure.

Comment 5

[Asko Tontti]

Seeing with PC Linux 2001111109. For me mozilla crashed immediately after
clicking the link.

Comment 6

[Olav Vitters]

Crashes Linux Build-ID 2001111006, talkback TB37871664G

Comment 7

[Boris Zbarsky [:bzbarsky]]

Um... xp apps.  ccing pavlov and blizzard for gtk fu.

Comment 8

[Christopher Blizzard (:blizzard)]

Actually, this crash is happening down in nsWebShellWindow::HandleEvent() which
means it's in xpfe.  Over to bryner who just _loves_ those focus bugs.

Comment 9

[sairuh (rarely reading bugmail)]

interestingly, i don't get a crash when using a winNT build --but i do crash
when using either linux *or* mac os 10.1 bits. os x crash report below. tested
using 2001.11.14-comm bits.

Date/Time:  2001-11-14 18:39:49 -0800
OS Version: 10.1 (Build 5L17b)

Command:    Netscape 6
PID:        292

Exception:  EXC_BAD_INSTRUCTION (0x0002)
Code[0]:    0x00000002
Code[1]:    0x00001700

Thread 0:
 #0   0x00001700 in 0x1700
 #1   0x01e2b7a8 in StoreBoundsToXUL__16nsWebShellWindowFiii
 #2   0x01e28ed8 in HandleEvent__16nsWebShellWindowFP10nsGUIEvent
 #3   0x01e611f8 in DispatchEvent__8nsWindowFP10nsGUIEventR13nsEventStatus
 #4   0x01e612cc in DispatchWindowEvent__8nsWindowFR10nsGUIEvent
 #5   0x01e6f304 in DispatchGuiEvent__25nsMacEventDispatchHandlerFP8nsWindowUi
 #6   0x01e6f5ec in SetActivated__25nsMacEventDispatchHandlerFP8nsWindow
 #7   0x01e70c2c in HandleActivateEvent__17nsMacEventHandlerFR11EventRecord
 #8   0x01e6fb24 in HandleOSEvent__17nsMacEventHandlerFR11EventRecord
 #9   0x01e6ed14 in HandleOSEvent__11nsMacWindowFR11EventRecord
 #10  0x01e742d4 in DispatchOSEvent__16nsMacMessageSinkFR11EventRecordP15OpaqueWin
 #11  0x01e783e8 in DispatchOSEventToRaptor__16nsMacMessagePumpFR11EventRecordP15O
 #12  0x01e7828c in DoActivate__16nsMacMessagePumpFR11EventRecord
 #13  0x01e77828 in DispatchEvent__16nsMacMessagePumpFiP11EventRecord
 #14  0x01e774cc in DoMessagePump__16nsMacMessagePumpFv
 #15  0x01e76e28 in Run__10nsAppShellFv
 #16  0x01e2f354 in Run__17nsAppShellServiceFv
 #17  0x004bb510 in main1__FiPPcP11nsISupports
 #18  0x004bc0b8 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: 0x00001700 srr1: 0x0008f030                vrsave: 0x00000000
   xer: 0x20000008   lr: 0x01e2b7a8  ctr: 0x00001700   mq: 0x00000000
    r0: 0x00001700   r1: 0xbfffef40   r2: 0x00001900   r3: 0x03df0c80
    r4: 0x00000001   r5: 0x00000001   r6: 0x00000001   r7: 0x000e002c
    r8: 0x00000002   r9: 0x80240998  r10: 0x000461a0  r11: 0x800033fc
   r12: 0x00700061  r13: 0x00000000  r14: 0x00000013  r15: 0x0005e7f0
   r16: 0x00000002  r17: 0x80160e88  r18: 0x00059558  r19: 0x00001707
   r20: 0x00000000  r21: 0x0000001c  r22: 0x70004bc4  r23: 0x70004c58
   r24: 0x7016b214  r25: 0x006bac3c  r26: 0x8081ab5c  r27: 0xc0dc2000
   r28: 0x00000000  r29: 0xbfffef00  r30: 0x00000000  r31: 0x00000001

Comment 10

[Brian Ryner (not reading)]

This has been fixed by my patch for bug 107844.  There is a new problem that
this exposes where the popup window immediately closes.  This has been filed as
bug 120209.

Comment 11

[sairuh (rarely reading bugmail)]

tested using 2002.01.23.08 comm bits on linux rh7.2: following the original
recipe, i don't crash, but a window briefly appears then disappears. [covered by
the newer bug 120209.] so, vrfy'ing.