Closed
Bug 35362
Opened 25 years ago
Closed 25 years ago
Mac only: crash when click on Start Netscape in the new profile
Categories
(Core Graveyard :: Profile: BackEnd, defect, P3)
Tracking
(Not tracked)
VERIFIED
WORKSFORME
People
(Reporter: fenella, Assigned: racham)
Details
Attachments
(1 file)
|
23.36 KB,
text/plain
|
Details |
Mac (2000-04-10-08 M15)
Steps:
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•25 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.
Correcting component to profile manger.
Component: Back End → Profile Manager FrontEnd
Product: MailNews → Browser
We have the stack trace for you, Steve. See attached.
Keywords: beta2
QA Contact: lchiang → gbush
Comment 5•25 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
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
updates.
Thanks.
Comment 7•25 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*)+
000CC
07AD4440 PPC 180BE750 nsJSContext::CallEventHandler(void*, void*, unsigned
int, void*,
int*)+0008C
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•25 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
happening.
Not happenig with the latest M15 & M16 builds. It was a glitch probably caused
by appshell event handling. Marking worksforme.
Status: NEW → RESOLVED
Closed: 25 years ago
Resolution: --- → WORKSFORME
| Reporter | ||
Comment 10•25 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.
Status: RESOLVED → VERIFIED
Updated•9 years ago
|
Product: Core → Core Graveyard
You need to log in
before you can comment on or make changes to this bug.
Description
•