Closed Bug 43470 Opened 24 years ago Closed 24 years ago

crash closing new account wizard with confused text field

Categories

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

Product:
SeaMonkey
Component:
MailNews: Account Configuration
Platform:
x86
Linux
Type:
defect

Tracking

(Not tracked)

Status:
VERIFIED FIXED

People

(Reporter: jeziorek, Assigned: danm.moz)

Details

(Keywords: crash, Whiteboard: [dogfood-][nsbeta2-]) 

-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
Keywords: smoketest
re-assigning.
Assignee: mscott → alecf
Component: Networking - IMAP → Account Manager
Putting on [dogfood+] radar.
Whiteboard: [dogfood+]
QA Contact: lchiang → nbaca
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.
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...
Status: NEW → ASSIGNED
I didn't see any stack traces in Talkback from jeziorek@netscape.com dated 
today.

Alek - can you reproduce this again and enter a talkback report?  Thanks.
Severity: normal → critical
Keywords: crash
this just works for me, I'm not sure what else to tell ya.
Status: ASSIGNED → RESOLVED
Closed: 24 years ago
Keywords: smoketest
Resolution: --- → WORKSFORME
Whiteboard: [dogfood+] → [dogfood+] not reproducable
Build 2000-06-23-08M17: NT4, Linux 6.0, Mac 9.04
Marking Verified Worksforme. I tried all platforms including Linux.
Status: RESOLVED → VERIFIED
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)
Status: VERIFIED → REOPENED
Resolution: WORKSFORME → ---
oof! this is a different crash I think.. cc'ing blizzard and pav to see if 
they're heard about GTK timer crashes
Not that I know of.
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
Assignee: alecf → danm
Status: REOPENED → NEW
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. 
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!
Whiteboard: [dogfood+] not reproducable → [dogfood+] ETA???
  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.
Whiteboard: [dogfood+] ETA??? → [dogfood+] can't reproduce
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.
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.
thanks for the info.. sounds like the particular stack trace here was a freak 
occurance or something. Still waiting on another stack trace...
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. 
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. 





  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.
Summary: When creating a IMAP account it crashes after completed → crash closing new account wizard with confused text field
Unless this is more common, not for beta2.  Putting on [nsbeta2-].

jpatel, can you check Talkback for more occurances please?  Thanks!
Keywords: nsbeta3
Whiteboard: [dogfood+] can't reproduce → [dogfood-][nsbeta2- can't reproduce
Whiteboard: [dogfood-][nsbeta2- can't reproduce → [dogfood-][nsbeta2-] can't reproduce
  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.
Whiteboard: [dogfood-][nsbeta2-] can't reproduce → [dogfood-][nsbeta2-]
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.
  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.
Status: NEW → RESOLVED
Closed: 24 years ago → 24 years ago
Resolution: --- → FIXED
Could not reproduce this bug using 2000-08-01-04 M17 on Linux 6.1
Verified: Fixed
Status: RESOLVED → VERIFIED
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.
Status: VERIFIED → REOPENED
Resolution: FIXED → ---
  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+.
Status: REOPENED → RESOLVED
Closed: 24 years ago → 24 years ago
Resolution: --- → FIXED
Fix works on 2000-08-02-04 M18, Linux 6.1 Gnome. 
Need PDT approval for check in into m17 branch. 



Adding keyword to bugs which already show a nsbeta2 triage value in the status 
whiteboard so the queries don't get screwed up.
Keywords: nsbeta2
Status: RESOLVED → VERIFIED
Build Id: 2000-08-02-04 M18, Linux 6.1 Gnome. 
Verified: Fixed
Product: Browser → Seamonkey
You need to log in before you can comment on or make changes to this bug.