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

NEW
Unassigned

Status

()

Core
XUL
--
major
17 years ago
8 years ago

People

(Reporter: Mitesh Shah, Unassigned)

Tracking

Trunk
Future
x86
Linux
Points:
---

Firefox Tracking Flags

(Not tracked)

Details

(Reporter)

Description

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("@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

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.
Status: NEW → RESOLVED
Last Resolved: 17 years ago
Resolution: --- → INVALID
(Reporter)

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 
queue.

Comment 6

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

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. 
Status: RESOLVED → REOPENED
Resolution: INVALID → ---

Comment 8

16 years ago
->pavlov
Assignee: trudelle → pavlov
Status: REOPENED → NEW

Updated

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

Comment 10

14 years ago
retargeting
Target Milestone: mozilla1.0.1 → Future

Updated

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

Updated

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