changes in preferences not written to prefs.js

VERIFIED FIXED

Status

SeaMonkey
Preferences
P3
blocker
VERIFIED FIXED
18 years ago
13 years ago

People

(Reporter: sairuh (rarely reading bugmail), Assigned: John Bandhauer)

Tracking

Firefox Tracking Flags

(Not tracked)

Details

(Whiteboard: [PDT+])

Attachments

(3 attachments)

(Reporter)

Description

18 years ago
this is new, as of using today's comm bits on linux, at least [2000-02-04-08].

to repro:
0. check the initial state of, say, the default homepage by grep'ing your
prefs.js. eg, mine said

  user_pref("browser.startup.homepage", "http://bugzilla.mozilla.org");

1. open Prefs, go to Navigator panel.
2. change the default homepage to, say, http://www.google.com
3. click OK.
4. grep prefs.js to observe the [lack of] change.

what's really bizarre was that for a while shrir wasn't able to repro this (same
bits, same platform) till he suddenly got a crash opening prefs (see bug 26588).
after restarting seamonkey, he can no longer change his homepage.

moreover, this might affect all of prefs, since syd chatted with me recently
about similar problems when trying to change IM prefs. syd, could you pls
provide further details (which panel, platform, etc)?
(Reporter)

Comment 1

18 years ago
nominating for beta1.

added zach@math.berkeley.edu, in case he has seen this.

btw, lemme know if this is a dup of another, larger bug that has recently
cropped up.
Keywords: beta1, dogfood

Comment 2

18 years ago
Seeing on mac commercial build also (2000020410m14). Changing PLATFORM and OS to 
ALL.
OS: Linux → All
Hardware: PC → All
Summary: changes in preferences not written to prefs.js → [PP]changes in preferences not written to prefs.js

Comment 3

18 years ago
I've seen this in accounts manager: bug 26580.  Haven't seen in prefs just
because they keep crashing me.
(Reporter)

Updated

18 years ago
Summary: [PP]changes in preferences not written to prefs.js → changes in preferences not written to prefs.js
(Reporter)

Comment 4

18 years ago
*** Bug 26600 has been marked as a duplicate of this bug. ***

Comment 5

18 years ago
it looks like this was caused by brendan's JS changes last night.
Looks like something broke with for (var i in associativeArray) when
associativeArray is an array of arrays.

Comment 6

18 years ago
This is dying the interpreter changes that
brendan made last night.   This does not look
like a front end problem at all
Assignee: ben → jband

Comment 7

18 years ago
If you back out brendans changes then it does not
crash so says danm.
(Assignee)

Comment 8

18 years ago
oh joy. I added rogerl to cc list and I'll email brendan. I'll look into it.
(Assignee)

Comment 9

18 years ago
With an old profile it changed the pref and all worked fine. I created a new 
profile and it crashed in JS when I clicked on the tree.

It crashes in jsemit line 654 where cx->fp->varobj == NULL
I'll attach a stack trace. and keep looking closer

    /*
     * We can't optimize if we're not compiling a function body, whether via
     * eval, or directly when compiling a function statement or expression.
     */
    obj = cx->fp->varobj;
    clasp = OBJ_GET_CLASS(cx, obj);
    if (clasp != &js_FunctionClass && clasp != &js_CallClass)
        return JS_TRUE;
(Assignee)

Comment 10

18 years ago
Created attachment 4943 [details]
stack of crash location

Comment 11

18 years ago
Putting on PDT+ radar for beta1.
Keywords: dogfood
Whiteboard: [PDT+]
rods saw that same crash doing File Open, which (of course!) WorksForMe.

cx->fp->varobj must not be null at the crashpoint, because js_CompileTokenStream 
sets up a frame with varobj set to the valid JSObject pointer that was passed to 
JS_Compile*.  Can someone able to reproduce the crash under a debugger verify 
that by going up the stack to js_CompileTokenStream and inspecting the "frame" 
local variable?

/be
Argh, timeouts for the openDialog-calling window are nesting in the dialog's 
modal event loop.  This seems bad, at least at first blush.  It also exposes a 
logic bug in my JS changes: I assumed no one would reuse a context to compile 
code that's already in use for the same scope.  Foolish me.  Patch to fix that 
(and the crash) coming right up.  Whether that fixes the for/in loop erratic 
behavior alecf saw, and helps save prefs and account state, we'll have to see.

/be
Created attachment 4946 [details] [diff] [review]
proposed crashbug fix -- helluva way to start a sabbatical!

Comment 15

18 years ago
*** Bug 26580 has been marked as a duplicate of this bug. ***

Comment 16

18 years ago
*** Bug 26568 has been marked as a duplicate of this bug. ***
Created attachment 4950 [details] [diff] [review]
shoot me now

Updated

18 years ago
Status: NEW → RESOLVED
Last Resolved: 18 years ago
Resolution: --- → FIXED
Fix checked into js/src/jsemit.c -- why am I still here?  Thanks to jband and 
alecf for help chasing this down.  Apologies to all,

/be

Comment 19

18 years ago
*** Bug 26588 has been marked as a duplicate of this bug. ***
(Reporter)

Comment 20

18 years ago
yay! verif w/2000-02-07-08 comm bits on linux and winNT.
Status: RESOLVED → VERIFIED

Comment 21

18 years ago
Bulk move of all Pref UI component bugs to new Preferences component.  Pref UI 
component will be deleted.
Component: Pref UI → Preferences
Product: Browser → Seamonkey
You need to log in before you can comment on or make changes to this bug.