26595 - changes in preferences not written to prefs.js

Status: VERIFIED FIXED

(SeaMonkey :: Preferences, defect, P3)

Description

[sairuh (rarely reading bugmail)]

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)?

Comment 1

[sairuh (rarely reading bugmail)]

nominating for beta1.

added [e-mail], in case he has seen this.

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

Comment 2

[shrirang khanzode]

Seeing on mac commercial build also (2000020410m14). Changing PLATFORM and OS to 
ALL.

Comment 3

[Richard Zach]

I've seen this in accounts manager: bug 26580.  Haven't seen in prefs just
because they keep crashing me.

Comment 4

[sairuh (rarely reading bugmail)]

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

Comment 5

[Alec Flett]

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

[matt]

This is dying the interpreter changes that
brendan made last night.   This does not look
like a front end problem at all

Comment 7

[matt]

If you back out brendans changes then it does not
crash so says danm.

Comment 8

[John Bandhauer]

oh joy. I added rogerl to cc list and I'll email brendan. I'll look into it.

Comment 9

[John Bandhauer]

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;

Comment 10

[John Bandhauer]

Attachment: stack of crash location

Comment 11

[leger]

Putting on PDT+ radar for beta1.

Comment 12

[Brendan Eich [:brendan]]

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

Comment 13

[Brendan Eich [:brendan]]

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

Comment 14

[Brendan Eich [:brendan]]

Attachment: proposed crashbug fix -- helluva way to start a sabbatical!

Comment 15

[Alec Flett]

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

Comment 16

[matt]

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

Comment 17

[Brendan Eich [:brendan]]

Attachment: shoot me now

Comment 18

[Brendan Eich [:brendan]]

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

[matt]

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

Comment 20

[sairuh (rarely reading bugmail)]

yay! verif w/2000-02-07-08 comm bits on linux and winNT.

Comment 21

[leger]

Bulk move of all Pref UI component bugs to new Preferences component.  Pref UI 
component will be deleted.