Closed
Bug 470648
Opened 16 years ago
Closed 16 years ago
[@ strcmp - nsChromeRegistry::Observe]
Categories
(Toolkit :: Startup and Profile System, defect)
Tracking
()
RESOLVED
INCOMPLETE
People
(Reporter: timeless, Unassigned)
Details
(Keywords: crash)
Crash Data
crash:
js> Components.classes["@mozilla.org/chrome/chrome-registry;1"].getService().nsIObserver.observe(null, null, null)
this isn't my crash, but it is definitely possible w/ today's codebase.
Signature strcmp
UUID f3b45f81-aff0-4ba5-a17f-f7c292081219
Time 2008-12-19 21:09:30-08
Uptime 1
Last Crash 10 seconds before submission
Product Firefox
Version 3.0.4
Build ID 2008102920
Branch 1.9
OS Windows NT
OS Version 5.1.2600 Service Pack 2
CPU x86
CPU Info GenuineIntel family 6 model 15 stepping 13
Crash Reason EXCEPTION_ACCESS_VIOLATION
Crash Address 0x0
Comments
Crashing Thread
Frame Module Signature [Expand] Source
0 mozcrt19.dll strcmp strcmp.asm:83
1 xul.dll nsChromeRegistry::Observe mozilla/chrome/src/nsChromeRegistry.cpp:1452
2 xul.dll nsCOMPtr_base::assign_from_gs_contractid nsCOMPtr.cpp:132
3 @0x6fdc7
Summary: [@ nsChromeRegistry::Observe] → [@ strcmp - nsChromeRegistry::Observe]
Comment 1•16 years ago
|
||
chrome reg isn't rdf for quite a while, Benjamin, can you put that bug where it should be?
Component: RDF → General
QA Contact: rdf → general
Comment 2•16 years ago
|
||
I only see one of these; the stack is mangled or bogus, and passing a null topic to ::Observe is completely unexpected. Not something I want to guard against, although if a better crash stack becomes available that shows the caller, I'd like to see it.
Status: NEW → RESOLVED
Closed: 16 years ago
Component: General → Startup and Profile System
Product: Core → Toolkit
QA Contact: general → startup
Resolution: --- → INCOMPLETE
Assignee | ||
Updated•13 years ago
|
Crash Signature: [@ strcmp - nsChromeRegistry::Observe]
You need to log in
before you can comment on or make changes to this bug.
Description
•