Closed Bug 494810 Opened 16 years ago Closed 16 years ago

"ASSERTION: GetSessionStorageForPrincipal got a storage that could not be accessed!"

Categories

(Core :: DOM: Core & HTML, defect)

x86
macOS
defect
Not set
normal

Tracking

()

RESOLVED DUPLICATE of bug 494543

People

(Reporter: jruderman, Assigned: sicking)

Details

(Keywords: assertion)

Attachments

(1 file)

I've been hitting this assertion on shutdown frequently this week.  The assertion was added a few months ago in bug 458091, but I'm only hitting it now.  I have browser.sessionstore.resume_from_crash set to false, in case that matters.

###!!! ASSERTION: GetSessionStorageForPrincipal got a storage that could not be accessed!: 'canAccess', file /Users/jruderman/central/docshell/base/nsDocShell.cpp, line 2200
I was going to suggest that this was caused by bug 494543, but it hasn't landed yet. Might be related, though.
This assert firing scares me.  A lot.
Flags: blocking1.9.1?
Any further information how to reproduce this? Would be great to call DumpJSStack() in gdb from xpc3250.so context (e.g. XPCWrappedNative::CallMethod frame) to get JS callstack or at least know what pages were open during exit.
Assignee: nobody → jonas
Flags: blocking1.9.1? → blocking1.9.1+
I was able to get this assertion during shutdown. It's quit likely it's this bug. JS stack shows this bug is duplicate of bug 494543.
Flags: blocking1.9.1+ → blocking1.9.1?
Sorry, mid-air turned the b191 flag back to ?. I don't have permissions to make it blocking again...
No longer hitting this now that bug 494543 is fixed :)
Status: NEW → RESOLVED
Closed: 16 years ago
Resolution: --- → DUPLICATE
No need to ask for blocking on a dupe.
Flags: blocking1.9.1?
Component: DOM → DOM: Core & HTML
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: