137815 - crash hitting Enter key before panel content finishes loading [@nsTreeSelection::FireOnSelectHandler]

Status: VERIFIED WORKSFORME

(SeaMonkey :: Preferences, defect)

Description

[Stefan Fleiter (:sfleiter)]

From Bugzilla Helper:
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:0.9.9+) Gecko/20020414
BuildID:    2002041407

When I start mozilla and open the prefernces, choose advanced by keyboard and
hit enter when advanced is highlighted the browser crashes.

Reproducible: Always
Steps to Reproduce:
1.close mozilla
2.open mozilla again
3.open preferences (Edit, Preferneces)
4.don't use your mouse any more
5.choose advanced
6.hit enter
7.see crash

Actual Results:  crash

Expected Results:  no crash

Talkback-ID: 5270537K

Comment 1

[Andrew Schultz]

confirming with linux build 20020415.  The key to reproduce seems to be switch
the pref category (using an arrow key) and hitting enter (to close the
prefernces window) quickly before the right panel has painted.

I am unable to reproduce this by using the mouse by clicking the new category
and hitting Enter, or by switching the category by using the arrow key and
hitting "Ok" with the mouse.  So this is probably Event Handling.

Comment 2

[qaz2]

Confirmed on 2002041603 on Mac OS 9.2.2, so setting Platform and OS to all.

Comment 3

[Andrew Schultz]

Linux Debug build throws an assertion before crashing

###!!! ASSERTION: You can't dereference a NULL nsCOMPtr with operator->().:
'mRawPtr != 0', file ../../../../../../dist/include/xpcom/nsCOMPtr.h, line 650
###!!! Break: at file ../../../../../../dist/include/xpcom/nsCOMPtr.h, line 650

Comment 4

[Andrew Schultz]

Attachment: stacktrace

Comment 5

[sairuh (rarely reading bugmail)]

ugh, i'm seeing this on the branch as well: 2002.04.15.13-1.0.0 comm bits on
linux rh7.2. i'll grab the talkback info in a jiffy...

i can repro this using a debug mozilla trunk build (linux) (15 apr, ~9pm pdt),
but my trace differs from andrew's:

#0  0x41e9c8c1 in ?? ()
   from /home/orca/lizard/mozilla/dist/bin/components/libgklayout.so
#1  0x41e9b055 in ?? ()
   from /home/orca/lizard/mozilla/dist/bin/components/libgklayout.so
#2  0x401c8cd6 in nsTimerImpl::Fire (this=0x87d21d0) at nsTimerImpl.cpp:339
#3  0x401c9082 in handleTimerEvent (event=0x43300440) at nsTimerImpl.cpp:401
#4  0x401c0011 in PL_HandleEvent (self=0x43300440) at plevent.c:596
#5  0x401bfe7f in PL_ProcessPendingEvents (self=0x80ec6d8) at plevent.c:526
#6  0x401c215e in nsEventQueueImpl::ProcessPendingEvents (this=0x80ec6b0)
    at nsEventQueue.cpp:388
#7  0x409c1bba in ?? ()
   from /home/orca/lizard/mozilla/dist/bin/components/libwidget_gtk.so
#8  0x409c1805 in ?? ()
   from /home/orca/lizard/mozilla/dist/bin/components/libwidget_gtk.so
#9  0x40439f9e in g_io_unix_dispatch () from /usr/lib/libglib-1.2.so.0
#10 0x4043b773 in g_main_dispatch () from /usr/lib/libglib-1.2.so.0
#11 0x4043bd39 in g_main_iterate () from /usr/lib/libglib-1.2.so.0
#12 0x4043beec in g_main_run () from /usr/lib/libglib-1.2.so.0
#13 0x40356333 in ?? () from /usr/lib/libgtk-1.2.so.0
#14 0x409c26f6 in ?? ()
   from /home/orca/lizard/mozilla/dist/bin/components/libwidget_gtk.so
#15 0x4098008e in ?? ()
   from /home/orca/lizard/mozilla/dist/bin/components/libnsappshell.so
#16 0x08057b13 in main1 (argc=1, argv=0xbffff5c4, nativeApp=0x80921b0)
    at ../../dist/include/xpcom/nsCOMPtr.h:650
#17 0x0805880f in main (argc=1, argv=0xbffff5c4) at nsAppRunner.cpp:1762
#18 0x40581507 in ?? () from /lib/i686/libc.so.6

Comment 6

[sairuh (rarely reading bugmail)]

here's the trace from 2002.04.15.13-1.0.0 crashing:

nsTreeSelection::FireOnSelectHandler()
nsTreeSelection::SelectCallback()
nsTimerImpl::Process()
handleMyEvent()
PL_HandleEvent()
PL_ProcessPendingEvents()
nsEventQueueImpl::ProcessPendingEvents()
event_processor_callback()
our_gdk_io_invoke()
libglib-1.2.so.0 + 0xff9e (0x40399f9e)
libglib-1.2.so.0 + 0x11773 (0x4039b773)
libglib-1.2.so.0 + 0x11d39 (0x4039bd39)
libglib-1.2.so.0 + 0x11eec (0x4039beec)
libgtk-1.2.so.0 + 0x94333 (0x402b6333)
nsAppShell::Run()
nsAppShellService::Run()
netscape-bin + 0x8c79 (0x08050c79)
netscape-bin + 0x9457 (0x08051457)
libc.so.6 + 0x1c507 (0x404e1507) 

Comment 7

[sairuh (rarely reading bugmail)]

saari / joki, would either of you know what might be going on here?

Comment 8

[joki (gone)]

I don't see this on my Windows tip build.  Hitting enter makes the dialog go 
away (since the Enter key is sent to the default 'OK' button).  Beyond that I 
can say the stack doesn't resemble any of the common event crash traces.

Comment 9

[timeless]

could document be null?

Comment 10

[Paul Wyskoczka]

Marking nsbeta1+ [adt2]

Comment 11

[Blake Ross]

Attachment: patch

Comment 12

[Blake Ross]

-> me

Comment 13

[Brian Ryner (not reading)]

Comment on attachment 81387 [details] [diff] [review]
patch

r=bryner

Comment 14

[Ben Goodger (use ben at mozilla dot org for email)]

Comment on attachment 81387 [details] [diff] [review]
patch

sr=[e-mail]

Comment 15

[Blake Ross]

fixed on trunk.

Comment 16

[sairuh (rarely reading bugmail)]

using 2002.04.29-trunk commercial bits on win2k and linux rh7.2, this no longer
crashes.

however, on mac 10.1.4, this still does crash for using 2002.04.29.08-trunk comm
bits. reopening, since the crash report (below) looks similar to the originally
reported ones.

OS Version: 10.1.4 (Build 5Q125)

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

Thread 0 Crashed:
 #0   0x0064e030 in 0x64e030
 #1   0x0061a87c in nsCOMPtr_base::assign_from_helper(nsCOMPtr_helper const &,
nsID const &)
 #2   0x02a3dd2c in nsTreeSelection::FireOnSelectHandler(void)
 #3   0x02a3af94 in nsTreeSelection::SelectCallback(nsITimer *, void *)
 #4   0x00626d84 in nsTimerImpl::Fire(void)
 #5   0x00626f1c in handleTimerEvent(TimerEventType *)
 #6   0x005f18c0 in PL_HandleEvent
 #7   0x005f172c in PL_ProcessPendingEvents
 #8   0x0059739c in nsEventQueueImpl::ProcessPendingEvents(void)
 #9   0x01f17a3c in nsMacNSPREventQueueHandler::ProcessPLEventQueue(void)
 #10  0x01f178e0 in nsMacNSPREventQueueHandler::RepeatAction(EventRecord const &)
 #11  0x01e8fb14 in Repeater::DoRepeaters(EventRecord const &)
 #12  0x01f2dcc8 in nsMacMessagePump::DispatchEvent(int, EventRecord *)
 #13  0x01f2d9f0 in nsMacMessagePump::DoMessagePump(void)
 #14  0x01f2d36c in nsAppShell::Run(void)
 #15  0x01e5fbcc in nsAppShellService::Run(void)
 #16  0x004c9e4c in main1(int, char **, nsISupports *)
 #17  0x004ca88c in main

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   0x70283ea4 in TSWaitOnConditionTimedRelative
 #3   0x7027d748 in TSWaitOnSemaphoreCommon
 #4   0x702c2078 in TimerThread
 #5   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   0x70026a2c in _pthread_become_available
 #3   0x70026724 in pthread_exit
 #4   0x70020550 in _pthread_body

PPC Thread State:
  srr0: 0x0064e030 srr1: 0x0000f030                vrsave: 0x00000000
   xer: 0x00000014   lr: 0x0061a69c  ctr: 0x0061a670   mq: 0x00000000
    r0: 0x0061a87c   r1: 0xbffff0d0   r2: 0x00101000   r3: 0x03373e30
    r4: 0x02a717b4   r5: 0xbffff148   r6: 0x03373e30   r7: 0x00000000
    r8: 0x00000066   r9: 0x00000000  r10: 0xffffffff  r11: 0x00000000
   r12: 0x00000001  r13: 0x00000000  r14: 0x00000000  r15: 0x00000000
   r16: 0x00000000  r17: 0x00000000  r18: 0x00000000  r19: 0x00000000
   r20: 0x00000000  r21: 0x00000000  r22: 0xbffff600  r23: 0x00000000
   r24: 0x004e13f8  r25: 0x004e1318  r26: 0x0010b2e0  r27: 0x004e15bc
   r28: 0x001119fc  r29: 0xbffff1b0  r30: 0x001119fc  r31: 0xbffff1c0

Comment 17

[Blake Ross]

(number of mac users) - (number who switch pref panels using arrow keys) -
(number who press enter very quickly after doing so, at the right moment) = I
don't think this is a priority.

Comment 18

[Blake Ross]

adt: reread last comment...

Comment 19

[Jaime Rodriguez, Jr.]

adt1.0.0+ (on ADT's behalf) approval for checkin to the 1.0 brnach. Pls check
this in after you receive a= from Drivers, then add the fixed1.0.0 keyword.

Comment 20

[Blake Ross]

Round and round we go!  Reread comment 7. I'm making the case that there's no
reason to spend any more time on this.  It only occurs on Mac now, and only in
very awkward and uncommon conditions.

Comment 21

[Andrew Schultz]

this does occur on the 1.0 branch on other platforms (linux build 20020504). 
the patch has no risk of cauing problems -- should it not be checked into the
branch?
(and I think you meant comment 17)

Comment 22

[Blake Ross]

sorry, you're right - resetting to adt+ for branch checkin, and then I'll get
this minused.

Comment 23

[Asa Dotzler [:asa]]

Comment on attachment 81387 [details] [diff] [review]
patch

a=asa (on behalf of drivers) for checkin to the 1.0 branch

Comment 24

[Blake Ross]

checked in on branch.

Comment 25

[Asa Dotzler [:asa]]

adding fixed1.0.0 keyword (branch resolution). This bug has comments saying it
was fixed on the 1.0 branch and a bonsai checkin comment that agrees. To verify
the bug has been fixed on the 1.0 branch please replace the fixed1.0.0 keyword
with verified1.0.0.

Comment 26

[sairuh (rarely reading bugmail)]

verified fixed on branch for win2k and linux rh7.2 (2002.06.27.0x comm bits).

still an issue for mac 10.1.5 --added relnote kw.

Comment 27

[Andrew Schultz]

this is now Mac-only

Comment 28

[(not reading, please use [e-mail] instead)]

for the mac only problem, I may have a wall paper patch.

see bug #203431

sarah, can you still reproduce this?

Comment 29

[(not reading, please use [e-mail] instead)]

I've landed my fix for #203431.

sarah, did that fix appear to fix this, too?

Comment 30

[sairuh (rarely reading bugmail)]

interestingly, i can no longer repro this crash on OS X (using 10.2.5 nowadays).
tested with builds (comm trunk) from 2003.04.24 and 2003.04.28. could this be
due to the fact that OS X builds are now mach-o, and somehow picked up some
goodness that way?

also searched through the crash reports i've had with nscp builds (since
february 2003), and couldn't find any similar-looking crashes.

marking w4m, based on the test case for accessing pref items with the keyboard.
will reopen if this crops up again.

Comment 31

[sairuh (rarely reading bugmail)]

v