On Tue, 26 Mar 2002, Kenneth J.Davis wrote:
>
> What I believe actually fixes this particular problem, but
> leaves the possibility of other such issues, in XAP_Frame change
> all uses of m_iIdAutoSaveTimer from an UT_Timer's identifier
> to a pointer to the actual UT_Timer. This makes the problem
> go away (no longer tried to delete an invalid m_pRedrawUpdateTimer),
> and prevents some unable to find timer [X] messages (within XAP_Frame).
> If my assumptions are correct, then this is a fix, otherwise it
> is simply changing memory layout so something else is corrupted.
This would work and would be easy to change for the Unix builds too.
>
> 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.
> Anyway, I'll see about making a proper patch tommorrow (assuming
> the bug still appears -- I wish I had a memory debugger/checker for Win32).
>
Thanks! I'd do something along either of theese lines.
Cheers
Martin
