511135 - crash in AppendUTF8toUTF16 during startup due to large sessionstore.js

Status: RESOLVED WORKSFORME

(Firefox :: Session Restore, defect)

Description

[Wayne Mery (:wsmwk)]

crash during startup sesssionrestore 
[@ free | js3250.dll@0xb00ae] v3.7
[@ mozcrt19.dll@0x9b68] v3.6

sessionstore.js is ~86Meg.
I had restarted shortly before this with no problem.
Then updated to 3.7a (from 3.6 dated 20090708)
I attempted to restore a second level (deep) about:sessionrestore
crash

safe mode also crashes
note: attached windbg is using v3.6

v3.6 crash with same session store
Signature mozcrt19.dll@0x9b68 
UUID 8f49b112-fdb0-41ff-983d-683632090818 
Time  2009-08-18 07:59:57.26093 
Uptime 36 
Last Crash 153 seconds before submission 
Product Firefox 
Version 3.6a1pre 
Build ID 20090708042452 
Branch 1.9.2 
OS Windows NT 
OS Version 6.0.6002 Service Pack 2 
CPU x86 
CPU Info GenuineIntel family 6 model 15 stepping 6 
Crash Reason EXCEPTION_ACCESS_VIOLATION 
Crash Address 0x0 
User Comments  
Processor Notes  

Crashing Thread
Frame Module Signature [Expand] Source 
0 mozcrt19.dll mozcrt19.dll@0x9b68  
1 js3250.dll js3250.dll@0x37224  
2 js3250.dll js3250.dll@0x3f110  
3 xul.dll xul.dll@0xb5875  
4 xul.dll xul.dll@0x83897  
5 xul.dll xul.dll@0x291e7d  
6 xul.dll xul.dll@0x13a8b6 


v3.7 crash example (the first crash of the day)
free | js3250.dll@0xb00ae 
bp-2913e6e1-9965-48da-90d8-6e58c2090818 
Time  2009-08-18 06:35:40.652675 
Uptime 135 
Product Firefox 
Version 3.7a1pre 
Build ID 20090817050221 
OS Windows NT 
OS Version 6.0.6002 Service Pack 2 
CPU x86 
CPU Info GenuineIntel family 6 model 15 stepping 6 
Crash Reason EXCEPTION_ACCESS_VIOLATION 
Crash Address 0x0 
User Comments browsing about:sessionrestore while another sessionrestore is being restored 
Processor Notes  

Crashing Thread
Frame Module Signature [Expand] Source 
0 mozcrt19.dll free obj-firefox/memory/jemalloc/crtsrc/jemalloc.c:6387  
1 js3250.dll js3250.dll@0xb00ae  
2 js3250.dll js_Interpret js/src/jsops.cpp:2167  
3 js3250.dll js_Invoke js/src/jsinterp.cpp:1379  
4 xul.dll nsXPCWrappedJSClass::CallMethod js/src/xpconnect/src/xpcwrappedjsclass.cpp:1670  
5 xul.dll nsXPCWrappedJS::CallMethod js/src/xpconnect/src/xpcwrappedjs.cpp:570  
6 xul.dll PrepareAndDispatch xpcom/reflect/xptcall/src/md/win32/xptcstubs.cpp:114  
7 xul.dll SharedStub xpcom/reflect/xptcall/src/md/win32/xptcstubs.cpp:141  
8 nspr4.dll nspr4.dll@0xca1f  
9 xul.dll nsTimerImpl::Fire xpcom/threads/nsTimerImpl.cpp:435  
10 xul.dll xul.dll@0x968d27

Comment 1

[Wayne Mery (:wsmwk)]

examples from other people during session restore
bp-bfea8e64-1e92-4377-94b6-ca0c92090815
bp-aba4c52c-a806-4313-9607-7785e2090816

Comment 2

[Wayne Mery (:wsmwk)]

morning memory is gradually returning. I originally decided to restart FF because I was getting frequent short UI hangs, and then I saw memory was bouncing between  ~500MB and ~1G. Been doing this for a few days I think, even across restarts. So perhaps that symptom is related to this eventual crash

Comment 3

[Simon Bünzli]

This issue is likely related to bug 467409 and thus bug 464350: The session Wayne sent me contains two huge strings containing recursive about:sessionrestore data (i.e. about:sessionrestore containing itself containing itself with different whole sessions yet - or never - to be restored) which we really should try to prevent somehow - or maybe at least flatten out so that we don't get megabytes worth of escape characters: \\\\\\\\\\\...

Comment 4

[Wayne Mery (:wsmwk)]

if it makes any difference, my normal method of "restarting" FF is to kill the windows task, then respond to the prompt about restoring sessions - I almost never use shutdown.  In the file I sent to Simon I would guess there is a legitimate sessionrestore at least 3 deep that I hadn't gotten back to.

Happy to be a guinea pig for any fixes that fix the bad file or prevent it.

Comment 5

[Wayne Mery (:wsmwk)]

Simon, thanks for checking my file. What's the recipe for editing it so I can put it back in a mostly usable state?

Comment 6

[Simon Bünzli]

(In reply to comment #5)
At that size, editing isn't really a viable solution anymore, I'm afraid. If possible, start over and then try to get used to close Firefox as everybody else (e.g. File -> Exit).

Comment 7

[Wayne Mery (:wsmwk)]

starting over doesn't excite me and I'm up for fixing it, I just need to know how.  I hacked with SciTE - it looks like maybe I'm only 1 deep in sessionstores, does that sound right?  I changed all \\\\ to single "\" and  depth, so it's 10meg and starts. But second nested sessionrestore comes up empty, so I did something wrong. Does the second nesting need \\?

Are saying killing the process definitely caused the problem, and File>Exit avoids it?  (been doing that for about a year after getting burned once by shutdown ... yes a long time ago)

Comment 8

[Simon Bünzli]

(In reply to comment #7)
> Does the second nesting need \\?

Yes, double the number of backslashes for every level you go deeper (this exponential growth is what's causing the immense size and a part of the slowdown).

> Are saying killing the process definitely caused the problem

Not restoring a crashed session and then crashing it again is what's causing the issue. Instead of trying to remember to always restore it, not crashing it in the first place should be easier.

And if you don't want to risk getting burned again, you could always use the Session Manager extension to create and manage as many backup files as you desire.

Comment 10

[Wayne Mery (:wsmwk)]

my crash signatures related to this have morphed to 

mozalloc_abort(char const* const) | NS_DebugBreak_P | AppendUTF8toUTF16(nsACString_internal const&, nsAString_internal&)
bp-478f991e-7fbe-426f-a344-901422120613
bug 

and
EMPTY: no crashing thread identified; corrupt dump 
bp-73a01b9e-34e4-49e6-bcf0-9f92a2120615
ala bug 743221

Comment 11

[Wayne Mery (:wsmwk)]

(not my crashes)

bp-cbd20be7-c4c3-4f63-8d5c-507d42120924
0 xul.dll AppendUTF8toUTF16 xpcom/string/src/nsReadableUtils.cpp:201
1 xul.dll AppendUTF8toUTF16 xpcom/string/src/nsReadableUtils.cpp:227
2 xul.dll NS_ConvertUTF8toUTF16::NS_ConvertUTF8toUTF16 obj-firefox/dist/include/nsString.h:145
3 xul.dll nsNativeAppSupportWin::Start toolkit/xre/nsNativeAppSupportWin.cpp:646
4 xul.dll XREMain::XRE_mainStartup toolkit/xre/nsAppRunner.cpp:3333
5 xul.dll XREMain::XRE_main toolkit/xre/nsAppRunner.cpp:3846 

bp-01904d2f-4994-42bd-bf51-50e3c2120918
bp-0b2f45ba-fb50-4f0b-90b0-5f7e92120927


I see other crashes which are not startup:
bp-815e522c-b028-438c-bc19-962472120919
bp-d0cc4336-982d-453f-a246-c3bcc2120921 (looks like user can reproduce)
bp-c5bb71e2-8b5f-453f-848e-37a072121003

Comment 12

[Wayne Mery (:wsmwk)]

Attachment: windbg stacktrace

I crashed on startup and didn't get a crash report. windbg stacktrace attached.

sessionrestore.js apparently mushroomed from 16MB to 40MB, and so restart crashed on the 40MB file. sad.

Comment 13

[Wayne Mery (:wsmwk)]

note: results with a failing json file are not determinant.  I crashed 2 of 3 startups on the same sessionrestore.js file - so one was successful startup

Comment 14

[Wayne Mery (:wsmwk)]

the two failures were 
bp-938b7e56-ebf7-40ee-b956-5fffa2121005
bp-53d32c13-2856-4e97-887c-543f82121005

Comment 15

[Virtual_ManPL [:Virtual] 🇵🇱 - (please needinfo? me - so I will see your comment/reply/question/etc.)]

I'm marking this bug as WORKSFORME as bug crashlog signature didn't appear from a long time (over half year) in Firefox (except some obsolete Fx <22, no crashes starting since Fx 22).