Open Bug 464350 Opened 16 years ago Updated 2 months ago

Firefox hangs in json.cpp:write_string when given a moderately-sized sessionstore.js file

Categories

(Core :: General, defect)

x86
All
defect

Tracking

()

People

(Reporter: dholbert, Unassigned)

References

Details

(Keywords: hang, perf)

Attachments

(2 files)

Attached file sessionstore.js
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.
Summary: Firefox hangs in json.cpp:write_string when given a moderately-sized "sessionstore.js" → Firefox hangs in json.cpp:write_string when given a moderately-sized sessionstore.js file
Attached file backtrace during hang
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.
Assignee: nobody → sayrer
(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.
Keywords: perf
OS: Linux → All
Assignee: sayrer → nobody
Severity: normal → S3
See Also: → 1849393
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Created:
Updated:
Size: