From: Saint-Denis (stdenisg@cedep.net)
Date: Thu Mar 28 2002 - 22:11:12 EST
About one year ago I made a patch to the windows timer. At the time the
timer ID was using an integer greater than 16 bits and provoked a bug with
Hewlett Packard printer drivers.
I suspected that the subject could resurface over, so I left some comments
and an UT_ASSERT to that effect in the file UT_Win32Timer.cpp. Please use
Windows timer IDs carefully ;)
Gilles Saint-Denis
----- Original Message -----
From: Martin Sevior <msevior@mccubbin.ph.unimelb.edu.au>
To: Kenneth J.Davis <jeremyd@computer.org>
Cc: <abiword-dev@abisource.com>
Sent: Wednesday, March 27, 2002 12:01 AM
Subject: Re: please comment, possible fix for 2912, involves UT_Timers
> > I believe a proper fix is to make sure the UT_Win32Timer
> > returns a unique and nonchanging id. I have an idea of how to
> > do this. But I'm open to suggestions, as they will probably be
> > simpler and better than what I'm considering; or if you think
> > I'm incorrect on this issue, let me know what you think the cause is
> > or suggestions to try to better isolate the cause. Right now the
> > crash occurs when attempting to delete a non NULL m_pRedrawUpdateTimer,
> > which definitely has the wrong id from any Timer's in the static
> > vector of timers (it appears to be pointing to already free'd
> > memory, though this is based on intuition and not fact).
> >
>
> Getting the windows UT_Timer to return a unique ID would be by far the
> best solution. The Unix timer function does this by construction.
>
> A really quick fix that fails about once in a billion is to just call
> UT_Rand() and use that for the timer ID. An alternatitive would be to
> invent UT_UniqueID which has private member variable which incremented
> after every request for a unique ID. Since the ID is local to each
> invocation of abiword it could just start at 0.
>
This archive was generated by hypermail 2.1.4 : Thu Mar 28 2002 - 22:10:55 EST