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

Status: RESOLVED INCOMPLETE

(Core :: XUL, defect)

Description

[Mitesh Shah]

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

[Stuart Parmenter]

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.

Comment 2

[Mitesh Shah]

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

[Brian Nesse (gone)]

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

[Stuart Parmenter]

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

[Simon Fraser [no longer active]]

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

[John Morrison]

May God have mercy on us all. The 212 bug spam-o-rama is Now!

Comment 7

[Mitesh Shah]

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. 

Comment 8

[Peter Trudelle]

->pavlov

Comment 9

[Asa Dotzler [:asa]]

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)

Comment 10

[Vedran Miletic]

retargeting

Comment 11

[Timea Cernea [:tbabos][inactive]]

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.