While testing crashes from bug 460924, I managed to pretty quickly generate a large-ish "sessionstore.js" file in my profile which basically hangs Firefox at startup. STEPS TO REPRODUCE: 1. Download attached sessionstore.js file, and put it in a new folder "myProfile" (or, put it in an existing profile) 2. Run "./dist/bin/firefox -profile myProfile -no-remote" (using a debug build of Firefox) ACTUAL RESULTS: Firefox hangs, not showing a window. It spends all of its time in a call to "json.cpp:write_string" with... buf = the contents of sessionstore.js len = the number of characters in sessionstore.js (375942 in this case) ( Link to code: http://tinyurl.com/5ks99c ) I'm not sure how long it hangs -- I just gave it 6 minutes, and it still wasn't done loading. I'm testing using a debug mozilla-central build, updated this morning. (at revision db2dd52d47c1) I have "ac_add_options --with-valgrind" enabled, if that matters.

Here's a backtrace during the hang. The function "write_string", where we spend all our time, is at level 9. AFAICT, we end up making a call to JS_ConcatStrings > JS_realloc > ... > arena_malloc_large for *each character in the string*. I think that's what ends up taking so much time.

(In reply to comment #1) > AFAICT, we end up making a call to JS_ConcatStrings > JS_realloc > ... > > arena_malloc_large for *each character in the string* sayrer corrected me in IRC -- we're doing that work for each *backslash* in the string, not each character. But since this sessionstore.js file is almost entirely backslashes[1], that still leaves us with a lot of work. [1] probably due to overzealous (and/or recursive) escaping in session store code.

going to switch to a buffer here instead of JSStrings, should fix the JSON half of this bug.

Is there a bug filed for the non-JASON half of the issue? With people getting ever larger sessionstore.js, this would be really nice to have.