Closed Bug 5795 Opened 26 years ago Closed 22 years ago

THREADING: CreateInstance critical section not protected

Categories

(Core :: XPCOM, defect, P2)

defect

Tracking

()

RESOLVED INVALID
Future

People

(Reporter: dougt, Assigned: dougt)

References

Details

nsComponentManager ignores CreateInstance critical section. nsComponentManager should place a monitor before and after the call to a components CreateInstance() meathod to avoid memory leaks or worse. An example of this is a singleton component. I may have code like this: if (mInstance == NULL) { mInstance = new nsProxyEventManager(); } return mInstance; If two or more threads are in a step lock state, mInstance will be allocated more than once. To avoid this, I would suggest the use of monitors similar to what is done with RegisterFactory().
Status: NEW → ASSIGNED
Priority: P3 → P2
Target Milestone: M6
Certainly a MP blocker. Will fix it for M6.
Target Milestone: M6 → M8
Summary: XPCOM - nsComponentManager ignores CreateInstance critical section → THREADING: CreateInstance critical section not protected
Target Milestone: M8 → M9
Target Milestone: M9 → M10
Target Milestone: M10 → M11
QA Contact: beppe → gerardok
Target Milestone: M11 → M13
Target Milestone: M13 → M14
The more I think about this, the more I dont want to do this. This would mean that componentmanager would hold a lock before calling out to create any instance in the module and release the lock after getting back control. What if the module turns around and calls cm for other things that would cause the same component to be created again. That would cause a deadlock. Any module holding a lock while calling out should be ultra cautious. I dont see a problem unless in the singleton case. I think I would be comfortable in saying the singleton should protect against threads just as it would in any multi threaded environment. Of course, any singleton mechanism we provide will take care of this. So I vote to WONTFIX this bug. Opinions. We can discuss this further in n.p.m.xpcom if you disagree.
Status: ASSIGNED → RESOLVED
Closed: 25 years ago
Resolution: --- → WONTFIX
Owner/reporter please verify, if applicable.
I am going to reopen. dp. we need to have a thread save version of the component manager. I believe that there is another bug like this.
Status: RESOLVED → REOPENED
Resolution: WONTFIX → ---
Reassigning to new default XPCOM owner, hoping jband will help. /be
Assignee: dp → scc
Status: REOPENED → NEW
QA Contact: gerardok → kandrot
Clearing out of date milestone (was M14) in hope of re-evaluation.
Target Milestone: M14 → ---
Status: NEW → ASSIGNED
Edward: I'd really love for you to become the XPCOM threading guy. Is that a possibility?
Assignee: scc → kandrot
Status: ASSIGNED → NEW
I will look into this and see what I can find out. I am not currently savy on the issues involved, so I will start with learning why it is needed and what the impact would be from doing this. I do not like needless locks, since it can kill a program, so I want to know all about the issues before I make any changes in this area.
Status: NEW → ASSIGNED
Target Milestone: --- → mozilla1.0
reassign all kandrot xpcom bug.
Assignee: kandrot → dougt
Status: ASSIGNED → NEW
Target Milestone: mozilla1.0 → ---
Target Milestone: --- → mozilla1.1
Blocks: 101976
this doesn't happen that often. futuring.
Target Milestone: mozilla1.1alpha → Future
ugh. what I am thinking.
Severity: normal → major
Target Milestone: Future → ---
Target Milestone: --- → Future
dp was right. the component manager can't hold a lock when calling out to factories.
Status: NEW → RESOLVED
Closed: 25 years ago22 years ago
Resolution: --- → INVALID
*** Bug 128646 has been marked as a duplicate of this bug. ***
You need to log in before you can comment on or make changes to this bug.