[Bug java/21524] New: Cancelling a TimerTask puts Timer binary heap in inconsistent state

[Bug java/21524] New: Cancelling a TimerTask puts Timer binary heap in inconsistent state

[jradel at 2wire dot com]

java/util/Timer uses a binary heap for its TimerTasks, using task.scheduled as
the key. Calling task.cancel() sets task.scheduled=-1, but doesn't update the
Timer binary heap. This can leave the binary heap in an inconsistent state --
the key shouldn't be modified while the task is in the binary heap. This can
lead to situations where newly scheduled TimerTasks aren't moved to the
appropriate position in the heap, so tasks might fire late (since they are stuck
behind tasks that aren't scheduled to fire for a while).

Attaching a proposed fix.

-- 
           Summary: Cancelling a TimerTask puts Timer binary heap in
                    inconsistent state
           Product: gcc
           Version: 3.4.1
            Status: UNCONFIRMED
          Severity: normal
          Priority: P2
         Component: java
        AssignedTo: unassigned at gcc dot gnu dot org
        ReportedBy: jradel at 2wire dot com
                CC: gcc-bugs at gcc dot gnu dot org,java-prs at gcc dot gnu
                    dot org


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21524

[Bug java/21524] Cancelling a TimerTask puts Timer binary heap in inconsistent state

[jradel at 2wire dot com]

------- Additional Comments From jradel at 2wire dot com  2005-05-11 23:39 -------
Created an attachment (id=8868)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=8868&action=view)
Fix for TimerTask cancel inconsistency in Timer binary heap


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21524

[Bug libgcj/21524] Cancelling a TimerTask puts Timer binary heap in inconsistent state

[pinskia at gcc dot gnu dot org]

-- 
           What    |Removed                     |Added
----------------------------------------------------------------------------
          Component|java                        |libgcj


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21524

[Bug libgcj/21524] Cancelling a TimerTask puts Timer binary heap in inconsistent state

[jradel at 2wire dot com]

------- Additional Comments From jradel at 2wire dot com  2005-05-12 18:32 -------
(From update of attachment 8868)
Ignore this first proposed fix... it's buggy. Working on a new version.


-- 
           What    |Removed                     |Added
----------------------------------------------------------------------------
Attachment #8868 is|0                           |1
           obsolete|                            |


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21524

[Bug libgcj/21524] Cancelling a TimerTask puts Timer binary heap in inconsistent state

[tromey at gcc dot gnu dot org]

------- Additional Comments From tromey at gcc dot gnu dot org  2005-05-13 16:30 -------
Could you write a reduced test case?
Ideally it would be in Mauve form; that way we can easily put it
in the test suite when we put in the fix.


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21524

[Bug libgcj/21524] Cancelling a TimerTask puts Timer binary heap in inconsistent state

[tromey at gcc dot gnu dot org]

------- Comment #4 from tromey at gcc dot gnu dot org  2006-06-21 20:09 -------
I looked at this a little today.
The code does look wrong, but I couldn't write a simple test case
to make it fail.  Do you have one?

One problem I see is that serve() uses the task's 'scheduled' field
without checking to see if it is == -1.


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21524

[Bug libgcj/21524] Cancelling a TimerTask puts Timer binary heap in inconsistent state

[rguenth at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21524

Richard Guenther <rguenth at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|UNCONFIRMED                 |WAITING
   Last reconfirmed|                            |2012-01-11
     Ever Confirmed|0                           |1

--- Comment #5 from Richard Guenther <rguenth at gcc dot gnu.org> 2012-01-11 14:01:44 UTC ---
Is this still an issue?