Closed Bug 24668 Opened 25 years ago Closed 25 years ago

[DOGFOOD]Crash when clicking on Finish on Account Setup

Categories

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

Product:
SeaMonkey
Component:
MailNews: Account Configuration
Type:
defect

Tracking

(Not tracked)

Status:
VERIFIED FIXED

People

(Reporter: fenella, Assigned: brendan)

References

Details

(Whiteboard: [PDT+] - fix in hand)

Attachments

(2 files)

macsbug log for crash on Finish acct setup
19.60 KB, text/plain
Details
the fix
611 bytes, patch
Details | Diff | Splinter Review 
Linux (2000-01-21-08 M13)
Win_nt (2000-01-21-09 M13)
Steps:
1. Launch Messenger using -mail
2. Select Edit|Account Setup and click on New Account to bring up New Messenger
Account Wizard
3. Click Next, enter Name and Email Id and click Next
4. Select Server and enter Server Name, click Next
5. Enter User Name and Password (optional on password), click Next until you see
Congratulations
6. Click the Finish button

Actual result: Messenger crashes

Expected result: should not crash, should create a new account

This occurs on Linux and Win_nt 4.0. Have not tested Mac yet.
It occurs both in POP and IMAP accounts
stack trace or incident ID por favor

Adding scottip and rjc to the CC. (hey that rhymes!)
Status: NEW → ASSIGNED
Crashes on Mac too.

very strange. This crashes in the JS engine, not in mail code, XPConnect or DOM
glue.

I have a build now, so I can start debugging this.
Talkback is hung up. Unable to get the starck trace.
QA Contact: lchiang → laurel
Summary: [Regression]Crash when clicking on Finish on Account Setup → [DOGFOOD]Crash when clicking on Finish on Account Setup
Blocks: 23744
Putting on the PDT+ radar.
Whiteboard: [PDT+]
*** Bug 24709 has been marked as a duplicate of this bug. ***
ok, this crash is completely in JavaScript.
The crash occurs on this line in the file:
http://lxr.mozilla.org/seamonkey/source/mailnews/base/prefs/resources/content/AccountWizard.js#242

Note that this is a blank line. Basically I put in lots of dump()'s, and
determined that the crash occurs AFTER the loop above this line has finished,
but BEFORE the next line begins to execute. I'm reassigning to brendan because
I'm totally lost on this.

Here's the top of the stack:
(gdb) where 15
#0  0x4006c54c in js_Interpret (cx=0x8762680, result=0xbfffc9d8)
    at jsinterp.c:1423
#1  0x4006ac7d in js_Invoke (cx=0x8762680, argc=1, flags=0) at jsinterp.c:682
#2  0x4007193a in js_Interpret (cx=0x8762680, result=0xbfffce3c)
    at jsinterp.c:2262
#3  0x4006ac7d in js_Invoke (cx=0x8762680, argc=0, flags=0) at jsinterp.c:682
#4  0x4007193a in js_Interpret (cx=0x8762680, result=0xbfffd2a0)
    at jsinterp.c:2262
#5  0x4006ac7d in js_Invoke (cx=0x8762680, argc=1, flags=0) at jsinterp.c:682
#6  0x4007193a in js_Interpret (cx=0x8762680, result=0xbfffd704)
    at jsinterp.c:2262
#7  0x4006ac7d in js_Invoke (cx=0x8762680, argc=1, flags=0) at jsinterp.c:682
#8  0x4007193a in js_Interpret (cx=0x8762680, result=0xbfffdb68)
    at jsinterp.c:2262
#9  0x4006ac7d in js_Invoke (cx=0x8762680, argc=1, flags=2) at jsinterp.c:682
#10 0x4006ae91 in js_InternalInvoke (cx=0x8762680, obj=0x8639968, 
    fval=140745120, flags=0, argc=1, argv=0xbfffdd1c, rval=0xbfffdca8)
    at jsinterp.c:759
#11 0x400514ef in JS_CallFunctionValue (cx=0x8762680, obj=0x8639968, 
    fval=140745120, argc=1, argv=0xbfffdd1c, rval=0xbfffdca8) at jsapi.c:2771
#12 0x403aee6f in nsJSContext::CallEventHandler (this=0x8762650, 
    aTarget=0x8639968, aHandler=0x86399a0, argc=1, argv=0xbfffdd1c, 
    aBoolResult=0xbfffdd20) at nsJSEnvironment.cpp:564
---Type <return> to continue, or q <return> to quit---
#13 0x403f6769 in nsJSEventListener::HandleEvent (this=0x873a288, 
    aEvent=0x881a2a4) at nsJSEventListener.cpp:128
#14 0x40def52f in nsEventListenerManager::HandleEventSubType (this=0x8734390, 
    aListenerStruct=0x873a2b8, aDOMEvent=0x881a2a4, aSubType=4)
    at nsEventListenerManager.cpp:640
(More stack frames follow...)

And the line is:
(gdb) frame 0
#0  0x4006c54c in js_Interpret (cx=0x8762680, result=0xbfffc9d8)
    at jsinterp.c:1423
1423			obj = JSVAL_TO_OBJECT(propobj->slots[JSSLOT_PARENT]);

(gdb) print propobj
$1 = (JSObject *) 0x85badc0
(gdb) print *propobj
$2 = {map = 0x560000, slots = 0x2383706}
(gdb) print *propobj->slots
Cannot access memory at address 0x2383706.
(gdb) print *propobj->map
Cannot access memory at address 0x560000.

Enjoy!
Assignee: alecf → brendan
Status: ASSIGNED → NEW
oh crap, assigned this to the wrong brendan address
Assignee: brendan → brendan
*** Bug 24843 has been marked as a duplicate of this bug. ***
2 things:

- Hey my bug was a dup, but it has a JS stack trace that might be useful.

- Anyone know a workaround to get an account profile constructed? I can't run 
any email code with this busted.
Putting on M13 radar.
Target Milestone: M13
*** Bug 24888 has been marked as a duplicate of this bug. ***
Crashed for creating new News account, too.
Whiteboard: [PDT+] → [PDT+] - no fix in hand
I don't suppose this could be because jsinterp.h defines the macro 
js_InternalCall() to call with flags == 0, rather than JSINVOKE_INTERNAL, could 
it?
jsalter@netcom.com: I wish it were that simple, but the JSINVOKE_INTERNAL flag 
is added by the common function called by those two macros (js_CallInternal and 
js_ConstructInternal).  Good idea though, cuz the skidmarks do look a lot like 
JS bytecodes (*propobj).  Are you debugging, or just inspecting the code?

/be
Status: NEW → ASSIGNED
Alec, were your gdb excerpts from a session on a big- or little-endian machine?

/be
Urgh, dyslexia: js_InternalCall and js_InternalConstruct became macros that call 
js_InternalInvoke, which supplies the JSINVOKE_INTERNAL flag.  But thanks to 
jsalter@netcom.com, I went on a hunt for calls to js_Invoke() and found the bad 
call in XPConnect.  Cursa me for commending it to jband long ago and not keeping 
track of it.  It's not a public API.  The fix is to use js_InternalCall.  I'm 
making it in the branch and trunk.

/be
The bad call is at 
http://lxr.mozilla.org/seamonkey/source/js/src/xpconnect/src/xpcwrappedjsclass.c
pp#726 -- the fix is to change the JS_FALSE argument to JSINVOKE_INTERNAL.  I'll 
check in as soon as someone says r=jband@netscape.com.

/be
Attached patch the fix — — Splinter Review 

    
  
Whiteboard: [PDT+] - no fix in hand → [PDT+] - fix in hand

    
    

    
  
Fix checked into SeaMonkey_M13_BRANCH (with optimized r=jband@netscape.com).  
Waiting for carwrec^H^H^H^Hpool in trunk to finish for trunk checkin.

/be

    
    

    
  
Retargeting milestone for trunk checkin.

/be
Target Milestone: M13 → M14

    
    

    
  
yay, thanks brendan! makes M13 FAR more useable


    
    

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

    
    

    
  
Thank jsalter@netcom.com, he had the right general idea for the problem: a 
rogue store due to lack of JSINVOKE_INTERNAL.

/be

    
    

    
  
brendan's fix to xpconnect's use of js_Invoke fixed this for me.

    
    

    
  
Fix checked into trunk.

/be
Status: ASSIGNED → RESOLVED
Closed: 25 years ago
Resolution: --- → FIXED

    
    

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

    
    

    
  
Damn, it worked.  I wasn't sure if it was actually a problem or not.

Actually, I'm trying to get mozilla to build on AIX 4.3.x and have been running 
into several issues along the way.  This was seen during some of my own 
build debugging...

    
    

    
  
Might I also suggest that with both js_CallInternal() and js_InternalCall() 
routines, you're asking for confusion going forward...

    
    

    
  
jsalter: huh?  There is only js_InternalCall (my hasty bug-commenting transposed 
words, but JS nomenclature puts adjectives before nouns when InterCapping).

/be

    
    

    
  
OK using 2000-01-25-15m13 commercial on linux 6.0

Will verify in both m13 and m14 (all platforms).

    
    

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

    
    

    
  
For the record:
bug 25036 was marked duplicate of this IN ERROR.

This bug (clicking Finish for a single account added) is ok using 2000-01-25-14
m13 commercial build on NT 4.0.

    
    

    
  
This bug (clicking Finish for a single account added) is ok using 2000-01-26-03
m13 commercial build on Mac.


    
    

    
  
I still see this with a build from this morning on linux ...

    
    

    
  
fenella, can you check Linux
Status: RESOLVED → REOPENED

    
    

    
  
Clearing Fixed resolution until we confirm Linux fix.
Resolution: FIXED → ---

    
    

    
  
I tried this on the M13 linux build 2000012520m13 and I did not crash clicking 
the Finish button and I added 2 account.  We need to know what build andreas is 
using M13 or M14.  Note: there are other bugs for random crashing in Account 
Setup, those may be what this persons is running into.  so I would say this bug 
as stated in original scenario, should be verified.  

    
    

    
  
I did in fact fix the M13 bug where XPConnect called js_Invoke by its old API, 
without a crucial flag argument.  That relieved the crash described in this 
report by alecf's backtrace and skidmarks (*propobj, etc.).  So I agree with 
esther, this bug should be closed.  Any other crashes should have their stacks 
compared to the ones in other account setup crash bugs (bug 25036, etc.) and 
added, or a new bug filed.

/be
Status: REOPENED → RESOLVED
Closed: 25 years ago → 25 years ago
Resolution: --- → FIXED

    
    

    
  
I'm on M14, so I agree. I will look for other bugs on this problem.

    
    

    
  
Linux Redhat 6.0 (2000-01-25-20 M13)
And Linux (2000-01-27-08 M14)
Using both M13 and M14 on Linux to verify this bug. It has been fixed. 


Status: RESOLVED → VERIFIED

    
    

    
  
I also checked WIn_nt 4.0 (2000-01-27-09 M14) and (2000-01-25-20 M13)
and  Mac (2000-01-26-03 M13) &  2000-01-27-08 M14) 
All fixed and verified.
Product: Browser → Seamonkey

          You need to log in
          before you can comment on or make changes to this bug.
        






  

    
  







  

    

      
Attachment

      

      
      
      
      
    

    

      

        

          

            
General

            

              Creator: 



            

            
Created: 

            
Updated: 

            
Size: