43470 - crash closing new account wizard with confused text field

Status: VERIFIED FIXED

(SeaMonkey :: MailNews: Account Configuration, defect, P3)

Description

[Alek Jeziorek]

-Start browser
-Tasks|Mail
-Edit|Mail/News account setting
-click on the new account button
-fill in all that they ask for and make you use a IMAP account at the finish it 
will crash everything and talkback will come up
 Linux comm. 2000-06-22-08-M17

Comment 1

[Scott MacGregor]

re-assigning.

Comment 2

[Jay Patel [:jay]]

Putting on [dogfood+] radar. 

Comment 3

[laurel]

I'm not able to reproduce using jun22 commercial build on linux rh6.0. I tried
adding an IMAP account to an existing profile and also tried a brand new
profile.

Comment 4

[Alec Flett]

Alek - do you have a stack trace? I'm wondering if your previous report about
not being able to create a pop account has left your account settings in a wierd
state...

Comment 5

[lchiang]

I didn't see any stack traces in Talkback from [e-mail] dated 
today.

Alek - can you reproduce this again and enter a talkback report?  Thanks.

Comment 6

[Alec Flett]

this just works for me, I'm not sure what else to tell ya.

Comment 7

[Ninoschka Baca]

Build 2000-06-23-08M17: NT4, Linux 6.0, Mac 9.04
Marking Verified Worksforme. I tried all platforms including Linux.

Comment 8

[Pratik Dhupia]

I see this bug in 2000-07-25-08 M17 on Linux 6.1. 

Steps to reproduce: 
 - same as done by nbaca but make sure you have an existing imap account. 

Reproducible: Always. 

Talkback ID: 14836680. 
Trigger Type:  Program Crash 
Trigger Reason:  SIGSEGV: Segmentation Fault: (signal 11) 

Call Stack:    (Signature = 0x00000000 eb0e5e97) 
 
   0x00000000 
                                                          
     
nsTimerGtk::FireTimeout() 
   process_timers() 
   TimerCallbackFunc() 
   libglib-1.2.so.0 + 0x10a04 (0x40753a04) 
   libglib-1.2.so.0 + 0xfbe6 (0x40752be6) 
   libglib-1.2.so.0 + 0x101a1 (0x407531a1) 
   libglib-1.2.so.0 + 0x10254 (0x40753254) 
   nsAppShell::DispatchNativeEvent() 
   nsXULWindow::ShowModal() 
   nsWebShellWindow::ConvertWebShellToDOMWindow() 
   nsChromeTreeOwner::FindItemWithName() 
   GlobalWindowImpl::OpenInternal() 
   GlobalWindowImpl::OpenDialog() 
   WindowOpenDialog() 
   js_Invoke() 
   js_Interpret() 
   js_Invoke() 
   js_InternalInvoke() 
   JS_CallFunctionValue() 
   nsJSContext::CallEventHandler() 
   nsJSEventListener::HandleEvent() 
   nsEventListenerManager::RegisterScriptEventListener() 
   nsEventListenerManager::HandleEvent() 
   GetRangeList() 
   PresShell::GetCurrentEventFrame() 
   nsMenuFrame::UpdateMenuSpecialState() 
   nsMenuPopupFrame::GetIsContextMenu() 
   PresShell::Paint() 
   PresShell::SetSubShellFor() 
   nsView::HandleEvent() 
   nsView::HandleEvent() 
   nsView::HandleEvent() 
   nsView::HandleEvent() 
   nsViewManager2::DispatchEvent() 
   HandleEvent() 
   nsWidget::DispatchEvent() 
   nsWidget::DispatchWindowEvent() 
   nsWidget::DispatchMouseEvent() 
   nsWidget::OnButtonReleaseSignal() 
   nsWindow::HandleGDKEvent() 
   dispatch_superwin_event() 
   handle_gdk_event() 
   libgdk-1.2.so.0 + 0x1700b (0x4072500b) 
   libglib-1.2.so.0 + 0xfbe6 (0x40752be6) 
   libglib-1.2.so.0 + 0x101a1 (0x407531a1) 
   libglib-1.2.so.0 + 0x10341 (0x40753341) 
   libgtk-1.2.so.0 + 0x8c209 (0x4067a209) 
   nsAppShell::Run() 
   nsAppShellService::EnumerateComponents() 
   main1() 
   main() 
   libc.so.6 + 0x181eb (0x402441eb) 
 

Comment 9

[Alec Flett]

oof! this is a different crash I think.. cc'ing blizzard and pav to see if 
they're heard about GTK timer crashes

Comment 10

[Christopher Blizzard (:blizzard)]

Not that I know of.

Comment 11

[Alec Flett]

In any case, this crash is not mail specific... this might be the js_GC
root_points_to_gcRoot assertion, but that is in bug 43466

Comment 12

[Pratik Dhupia]

Putterman: I do see this bug on the latest 2000-07-26-08 linux build. I could
reproduce the crash by attempting to create a second imap account under a brand
new profile. 

Comment 13

[leger]

Can we get an ETA on a fix for this?  Pratik, can you show danm on your machine 
this crash if he cannot reproduce?  Thanks!

Comment 14

[Dan M]

  Oh! An unexpected present!
  I see in the bug history that Alec couldn't reproduce this bug. I suppose 
that's why he gave it to me. I just gave myself six IMAP accounts with a Linux 
build made this morning, and had no problems.

Comment 15

[Alec Flett]

sorry dan - I just knew it couldn't be mail either.. I figure at the very least 
this COULD be the js_GC bug, in which case we can just mark it a dupe of that.

Comment 16

[Stuart Parmenter]

from looking at the timer code, the only thing i could see happening here would
be the timer getting destroyed but not removed from the internal timer list
correctly... this seems unlikely since nsTimerGtk's destructor removes the timer
from the lists immediatly... so unless we have a thread releasing a timer at the
same time as we are trying to fire it....

if this is the case, we got some issues.  Unfortunatly, I can't seem to
reproduce this bug either, so I don't know that this is the case, but its the
only conclusion I can come up with here.

Comment 17

[Alec Flett]

thanks for the info.. sounds like the particular stack trace here was a freak 
occurance or something. Still waiting on another stack trace...

Comment 18

[Pratik Dhupia]

More Stack Traces for this bug: 
14835799
14837184
14844301

Damn: I can reproduce the bug with y'day build and I can show it to you 
anytime before 4pm on my machine. 

Comment 19

[Pratik Dhupia]

Ok guys, this could help solve the great mystery. Usually when I try to create
an account, I mark the email address in the email address field with the mouse
first and type the new email address. If you do this and If this email address
is long enough (extends more than the text box) you will see the crash at the
end. It doesn't matter if the account is imap or pop. Unfortuntely, my email
addresses I was using with pop accounts were short which led me to believe this
was a imap issue. 

If anyone would like to see I could reproduce it on my machine. 

Comment 20

[Dan M]

  After working with Pratik for a while, I know what causes the crash. But I 
still can't reproduce it anywhere but on his machine (which has no debug symbols, 
and is therefore useless for debugging...)
  The key is to get the event system into a state where it's confused about 
whether the mouse is still down. You can do this by clicking in a text edit 
field, dragging the selection, continuing dragging until the mouse is outside the 
entire window containing the text field, and then releasing the mouse. With the 
mouse button not pressed, notice that the text field's selection still behaves as 
if the mouse button is pressed, as you return the mouse to the text field's 
window and move it around.
  The crash sequence we've repeated is: do the above thing in any text field of 
the New Account Wizard, and then hit the Next button at least once (moving to a 
new pane, hiding the confusd text field), and then close the window (either by 
hitting the Finish button, or hitting the close widget.) App crashes.
  Well, it does on Pratik's machine, anyway. It won't crash any of my machines.
  Other notes of interest: one of my machines is RedHat 6.0 with gtk+-1.2.3-1. A 
build on this machine exhibits the "confused text field" problem (though it 
doesn't crash.) Another machine I've tried is RedHat 6.0 with gtk+-1.2.8-1. A 
build on this machine does NOT exhibit the "confused text field" problem, and of 
course doesn't crash. The machine that crashes has RedHat 6.1 with gtk+1.2.5-2.
  So the whole problem probably evaporates on the most recent RedHat builds, 
though there are several other acknowledged problems like this with the Event 
State Manager.
  This is probably caused by the Event State Manager hanging on to the text 
widget after it's been destroyed. cc:ing saari and still searching for a 
developer machine that'll make the crash happen.

Comment 21

[leger]

Unless this is more common, not for beta2.  Putting on [nsbeta2-].

jpatel, can you check Talkback for more occurances please?  Thanks!

Comment 22

[Dan M]

  We've found a developer's machine that this happens on. So it looks like 60% of 
the machines tried have this problem, and it's the result of a pretty natural 
user gesture. Chris and I are working on this. Realizing it's been beta-minused, 
but not quite ready to let it go yet.

Comment 23

[Jay Patel [:jay]]

Tried looking in Talkback, and found a bunch of stack sigs starting with 
0x00000000, but they were all different than the one given here.  Sorry.  I can 
try tommorrow.

Comment 24

[Dan M]

  The undead text selection that lies at the root of this bug contains an 
autoscroll timer. This was firing, referencing the text field's frame after it 
had been deleted. I've added code to more thoroughly kill the autoscroll timer 
when the selection (and frame) are deleted.

Comment 25

[Pratik Dhupia]

Could not reproduce this bug using 2000-08-01-04 M17 on Linux 6.1
Verified: Fixed

Comment 26

[Pratik Dhupia]

Sorry folks, I hesitate to mark this fix now because I am able to reproduce the 
problem infrequently using 2000-08-01-04 M17 build on linux 6.1 GNome. 

Comment 27

[Dan M]

  Your M17 build doesn't have the fix. The status whiteboard says nsbeta2-, so 
the fix was checked in only on the trunk. Re-closing. I suppose the thing to do, 
if you want this fix checked in on M17 as well, is to talk to PDT and get it 
reopened nsbeta2+.

Comment 28

[Pratik Dhupia]

Fix works on 2000-08-02-04 M18, Linux 6.1 Gnome. 
Need PDT approval for check in into m17 branch. 

Comment 29

[Daniel Veditz [:dveditz]]

Adding keyword to bugs which already show a nsbeta2 triage value in the status 
whiteboard so the queries don't get screwed up.

Comment 30

[Pratik Dhupia]

Build Id: 2000-08-02-04 M18, Linux 6.1 Gnome. 
Verified: Fixed