If you think a bug might affect users in the 57 release, please set the correct tracking and status flags for Release Management.

Mac only: crash when click on Start Netscape in the new profile



Core Graveyard
Profile: BackEnd
18 years ago
2 years ago


(Reporter: fenella, Assigned: racham)


Mac System 8.6

Firefox Tracking Flags

(Not tracked)



(1 attachment)



18 years ago
Mac (2000-04-10-08 M15)
1. After installing netscape commercial build, click on Netscape icon from 
the desktop.
2. Click on Manage Profiles button from the left bottom.
3. Click on New Profile and click on Next
4. Create Profile dialog comes up, enter a new profile name, click Finish.
5. Back to the Select User Profile, select the newly created profile
6. Click on Start Netscape button
Actual result: crash occurs.
Expect result: should not crash, it should bring up the Account Wizard dialog.

This problem occurs on Mac only.
Win32 and Linux works fine.

Comment 1

18 years ago
Fenella, can we get a stack trace of this?  Can you work with a developer to
recreate this on a debug build if necessary?  Thx.

Comment 2

18 years ago
Created attachment 7440 [details]
crash log from the Mac

Comment 3

18 years ago
Correcting component to profile manger.
Component: Back End → Profile Manager FrontEnd
Product: MailNews → Browser

Comment 4

18 years ago
We have the stack trace for you, Steve. See attached.
Keywords: beta2
QA Contact: lchiang → gbush

Comment 5

18 years ago
Bhuvan, looks like someone broke us again.  I don't see us returning from the
Run() call here.  CCing Ben in case this really is frontend.
Assignee: selmer → racham
Component: Profile Manager FrontEnd → Profile Manager BackEnd

Comment 6

18 years ago
Looks like some event handling code is broken...

Adding Simon and Pierre to the cc list for their input.

Simon & Pierre,

Can you help us deciphering the Mac Stack trace and in identifying the code 
segment that is causing the problem ? Stack trace attached in one of the 

Comment 7

18 years ago
Well, the crash is in JavaScript, js_LockScope1. Here's the top of the stack:

  07AD4720    PPC  16575308  
nsEventListenerManager::HandleEventSubType(nsListenerStruct*, ns
IDOMEvent*, unsigned int, unsigned int)+003F0
  07AD44D0    PPC  1813A850  nsJSDOMEventListener::HandleEvent(nsIDOMEvent*)+
  07AD4440    PPC  180BE750  nsJSContext::CallEventHandler(void*, void*, unsigned 
int, void*,
  07AD4380    PPC  18570C24  JS_ValueToFunction+00018
  07AD4340    PPC  1858D050  js_ValueToFunction+00050
  07AD42E0    PPC  185980B8  js_GetSlotWhileLocked+0001C
  07AD4290    PPC  18598878  js_LockObj+0002C
  07AD4240    PPC  185986D8  js_LockScope1+00040

Ccing some JS folks.

Comment 8

18 years ago
I'm not sure what to say. There have been other bugs like this that turned out 
to be an event being sent to code in a window which was no longer around. The 
JSObject that the JS engine has been told to call is no longer valid and is just 
a garbage pointer. Eventually some dereference of garbage causes a crash.

The real problem is almost certainly upstream somewhere. If you can reproduce 
this in the debugger then maybe you can get a better sense of what exactly is 


Comment 9

18 years ago
Not happenig with the latest M15 & M16 builds. It was a glitch probably caused 
by appshell event handling. Marking worksforme.
Last Resolved: 18 years ago
Resolution: --- → WORKSFORME

Comment 10

18 years ago
Mac (2000-04-14-04 M15)
Mac (2000-04-14-09 M16)
I re-tested this bug on both M15 and M16 builds. it does not occur any more.


18 years ago
Keywords: nsbeta2
Product: Core → Core Graveyard
You need to log in before you can comment on or make changes to this bug.