Closed Bug 511135 Opened 15 years ago Closed 7 years ago

crash in AppendUTF8toUTF16 during startup due to large sessionstore.js

Categories

(Firefox :: Session Restore, defect)

x86
Windows Vista
defect
Not set
critical

Tracking

()

RESOLVED WORKSFORME

People

(Reporter: wsmwk, Unassigned)

References

Details

(Keywords: crash, Whiteboard: [startupcrash])

Crash Data

Attachments

(1 file)

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
examples from other people during session restore
bp-bfea8e64-1e92-4377-94b6-ca0c92090815
bp-aba4c52c-a806-4313-9607-7785e2090816
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
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: \\\\\\\\\\\...
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.
Simon, thanks for checking my file. What's the recipe for editing it so I can put it back in a mostly usable state?
(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).
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)
(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.
Depends on: 508740
Crash Signature: [@ free | js3250.dll@0xb00ae] [@ mozcrt19.dll@0x9b68]
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
Blocks: 743221
Crash Signature: [@ free | js3250.dll@0xb00ae] [@ mozcrt19.dll@0x9b68] → [@ free | js3250.dll@0xb00ae] [@ mozcrt19.dll@0x9b68]
Depends on: 517361
Summary: crash during startup sesssionrestore [@ free | js3250.dll@0xb00ae] [@ mozcrt19.dll@0x9b68] → crash during startup sesssionrestore [@ free | js3250.dll@0xb00ae] [@ mozcrt19.dll@0x9b68] due to large sessionstore.js
(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
Crash Signature: [@ free | js3250.dll@0xb00ae] [@ mozcrt19.dll@0x9b68] → [@ free | js3250.dll@0xb00ae] [@ mozcrt19.dll@0x9b68] [@ mozalloc_abort(char const* const) | NS_DebugBreak_P | AppendUTF8toUTF16(nsACString_internal const&, nsAString_internal&)]
Summary: crash during startup sesssionrestore [@ free | js3250.dll@0xb00ae] [@ mozcrt19.dll@0x9b68] due to large sessionstore.js → crash in AppendUTF8toUTF16 during startup due to large sessionstore.js
Whiteboard: [startupcrash]
Attached file 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.
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
Crash Signature: [@ free | js3250.dll@0xb00ae] [@ mozcrt19.dll@0x9b68] [@ mozalloc_abort(char const* const) | NS_DebugBreak_P | AppendUTF8toUTF16(nsACString_internal const&, nsAString_internal&)] → [@ free | js3250.dll@0xb00ae] [@ mozcrt19.dll@0x9b68] [@ mozalloc_abort(char const* const) | NS_DebugBreak_P | AppendUTF8toUTF16(nsACString_internal const&, nsAString_internal&)] [@ mozalloc_abort | NS_DebugBreak_P | AppendUTF8toUTF16]
See Also: → 1106264
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).
Status: NEW → RESOLVED
Closed: 7 years ago
Resolution: --- → WORKSFORME
You need to log in before you can comment on or make changes to this bug.