Re: please comment, possible fix for 2912, involves UT_Timers

From: Martin Sevior (msevior@mccubbin.ph.unimelb.edu.au)
Date: Wed Mar 27 2002 - 00:01:01 EST

  • Next message: Martin Sevior: "commit: Fix list bug."

    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

    This archive was generated by hypermail 2.1.4 : Wed Mar 27 2002 - 00:02:04 EST