Closed
Bug 95719
Opened 23 years ago
Closed 3 years ago
Gtk timer doesn't stay alive when it gets out of scope from the function
Categories
(Core :: XUL, defect)
Tracking
()
RESOLVED
INCOMPLETE
Future
People
(Reporter: mitesh, Unassigned)
Details
Windows and Mac works fine. They are addrefing themselves to hold a timer reference while gtk timer on Linux doesn't addref itself. So it gets deleted when it goes out of scope in following code sample: { nsCOMPtr<nsITimer> timer; timer = do_CreateInstance("@mozilla.org/timer;1",&rv); if (NS_FAILED(rv)) return rv; rv = timer->Init(this, 60*1000, NS_PRIORITY_NORMAL, NS_TYPE_REPEATING_SLACK); if (NS_FAILED(rv)) return rv; } The actual code is in nsAutoConfig.cpp at : http://lxr.mozilla.org/seamonkey/source/modules/libpref/src/nsAutoConfig.cpp#325
Comment 1•23 years ago
|
||
This is as designed. Timers are supposed to go away when their refcount hits 0. Holding on to them is bad.. mac and windows shouldn't do this. Whenever my new timer patch lands that makes all platforms share the same code, this will be the case. The reason that timers shouldn't refcount themselves is that it can cause the timer to walk back in to a deleted object's member function or what not. the nsAutoConfig code needs to hold a reference to the timer as long as it needs the timer to exist.
Status: NEW → RESOLVED
Closed: 23 years ago
Resolution: --- → INVALID
Reporter | ||
Comment 2•23 years ago
|
||
I am not sure if others are depending on the assumption that timer adds a reference to itself, particularly on windows and mac platform. Please make sure about that when you apply a new patch to timer code. I will change nsAutoConfig to have a member variable to hold a timer reference.
Comment 3•23 years ago
|
||
So this is special. The only way to fix the bug on linux is to write code which will cause a cyclical reference between the timer and the object holding the reference to it causing neither object to ever be removed on all other platforms. See bug 56659 and bug 85231. Can we make this work the same on all platforms soon?
Comment 4•23 years ago
|
||
Bug 78611 has a patch in it which has an XP timer implementation. As far as I know, the only issues are on the mac, where it didn't work at first pass... making it work should be trivial though. If you have time to work on this, it would be great. :)
Comment 5•23 years ago
|
||
I think I disagree with pavlov here. The timer callback can be a C function or a static method of a C++ class; there is no assumption that it will involve any object that must be 'kept alive', which is implied by the fact that the Unix timer code is requiring that someone else to hold a ref to the timer. So I see nothing wrong with having a timer whose only reference is held by the timer queue.
Comment 6•23 years ago
|
||
May God have mercy on us all. The 212 bug spam-o-rama is Now!
QA Contact: aegis → jrgm
Reporter | ||
Comment 7•23 years ago
|
||
I think the issue has not resolved yet. There shouldn't be an assumption that the object which creates a Timer should hold a reference.
Status: RESOLVED → REOPENED
Resolution: INVALID → ---
Updated•23 years ago
|
Target Milestone: --- → mozilla1.0
Comment 9•23 years ago
|
||
Bugs targeted at mozilla1.0 without the mozilla1.0 keyword moved to mozilla1.0.1 (you can query for this string to delete spam or retrieve the list of bugs I've moved)
Target Milestone: mozilla1.0 → mozilla1.0.1
Updated•17 years ago
|
Assignee: pavlov → jag
QA Contact: jrgmorrison → xptoolkit.widgets
Updated•16 years ago
|
Assignee: jag → nobody
Comment 11•3 years ago
|
||
Closing this as resolved:incomplete, last activity on this issue was 20 years ago and it doesn't have an assignee since that. Please re-open it if you consider it still relevant for today's Firefox.
Status: NEW → RESOLVED
Closed: 23 years ago → 3 years ago
Resolution: --- → INCOMPLETE
You need to log in
before you can comment on or make changes to this bug.
Description
•