Gtk timer doesn't stay alive when it gets out of scope from the function




17 years ago
8 years ago


(Reporter: Mitesh Shah, Unassigned)



Firefox Tracking Flags

(Not tracked)




17 years ago
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(";1",&rv);
            if (NS_FAILED(rv)) 
                return rv;
            rv = timer->Init(this, 60*1000, NS_PRIORITY_NORMAL, 
            if (NS_FAILED(rv)) 
                return rv;

The actual code is in nsAutoConfig.cpp at :

Comment 1

17 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.
Last Resolved: 17 years ago
Resolution: --- → INVALID

Comment 2

17 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

17 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

17 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

17 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 

Comment 6

17 years ago
May God have mercy on us all. The 212 bug spam-o-rama is Now!
QA Contact: aegis → jrgm

Comment 7

17 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. 
Resolution: INVALID → ---

Comment 8

16 years ago
Assignee: trudelle → pavlov


16 years ago
Target Milestone: --- → mozilla1.0

Comment 9

16 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 
Target Milestone: mozilla1.0 → mozilla1.0.1

Comment 10

14 years ago
Target Milestone: mozilla1.0.1 → Future


11 years ago
Assignee: pavlov → jag
QA Contact: jrgmorrison → xptoolkit.widgets


9 years ago
Assignee: jag → nobody
You need to log in before you can comment on or make changes to this bug.