Subject: Re: Zoom/spellcheck bug.
From: Thomas Fletcher (thomasf@qnx.com)
Date: Fri Oct 27 2000 - 11:27:26 CDT
On Fri, 27 Oct 2000, Martin Sevior wrote:
> On Fri, 27 Oct 2000, Thomas Fletcher wrote:
[Timer problem discussed]
>
> This was solved in the Unix dialogs by putting in some explicit
> handshaking with the timer callbacks. You can't delete a Unix Modeless
> dialog until the timer callback says its finished doing its stuff. As far
> as I can tell this works 100% of the time in the Unix code.
>
> Actually the solution might be to put this handshaking code into the
> Spellchecking Timer callback too. Have a look in ap_UnixFrame.cpp at the
> setzoompercentage method. Just add some code to kill spellchecking timer
> with some handsaking code to verify that is dead before the call to
> _showdocument(zoompercentage);
Yes but that means that we go around fixing each and every instance
of a timer to do this handshaking. It is much better to just put
in code in the destructor of all of the timers to NULL out their slot
and then let the event be processed as a NULL event. I find the
hand-shaking to be a (moderate, it does have other uses) was of
code since it is a general problem with timers and events.
> Look in ap_UnixDialog_WordCount.cpp and the destroy() method to see how I
> did the handshaking to safely kill the timer there.
I know how you did it, but there are lots of times that you
will want to create a timer in one module, delete it in
another where the extra hand-shaking is inaccessible. I'm
just thinking that our Timers are general purpose timers
and can be used for a variety of things. You should only
have to put hand-shaking in if your code needs it, not
because of a basic element design.
> Hmm I'm not sure if your general solution will work. How do you know if
> the pointer in the slot is valid? It is not NULL. I think a better
The timer destructor sets the slot to NULL. As I said, since
we are single threaded you don't need to lock the global slot
array (but later a mutex/condition variable around the slots
would prevent contention).
> solution is to make sure timer has returned from doing its thing before
> deleting it. We might be able to put in some general handshaking code to
> test this in the timer class. ie Two boolean variables.
> m_bDontDoTimerCodeNow and m_bImDoingMyThing.
> A callback is only executed if m_bDontDoTimerCodeNoew is False.
But how do you know how many timer events might be in the queue?
This is an OS abstraction that you might not have access to.
> Then m_bImDoingMyThing is set to true before jumping to the callback.
> After returning it's set to False. The timer delete method then sets
> m_bDontDoTimerCodeNow to True and only removes the timer when
> m_bImDoingMyThing is False.
Where are your handshaking variables when your object is deleted?
Essentially the slot is considered a handshake ... in a very
rudimentary fashion. If it is full, the object exists and you
can call out with the handler, if it is empty, then your ignore
the callout.
I know that code counts more than words, so I'll implement
a solution and you will see how little effort (and no code
change in any other part of the system) it takes to implement
this solution in a general sense.
When I get time ... =;-)
Thomas
> > > On Fri, 27 Oct 2000, David Schmitz wrote:
> > > > I've discovered an odd bug. It's been befuddling me for a couple of days
> > > > and I think I've finally tracked it down. I've been taking some old, old
> > > > text files and converting them to .rtf by hand; putting formatting,
> > > > typefaces, etc back into the document. Since I've been doing this on and
> > > > off, I've been saving, and reloadign the documents sporadically.
> > > >
> > > > One of the first things I do when I open up a document is to set the
> > > > zoom to the proper size. (140% is perfect for my monitor, so I plopped
> > > > that into the sources and did a recompile) When I choose 140% from teh
> > > > drop down menu, sometimes AbiWord would crash, and other times it would
> > > > not. My dander up, I decided to investigate. (My first issue was to get
> > > > rid of that damned GNOME segfault dialog so that the program could dump
> > > > a proper core file :-)
> > > >
> > > > After doing some experiementing, I noticed that the wp would die if I
> > > > did my zoom before the program is done putting those red lines under
> > > > misspelled words. If I do the zoom *after* the little red lines are all
> > > > drawn, the program happily chugs along without skipping a beat.
> > > >
> > > > After causing a crash, a post mortem backtrack on the core gives me this:
> > > >
> > > > (gdb) backtrace
> > > > #0 0x405f4d8f in ?? () from /lib/libc.so.6
> > > > #1 0x80bc1f5 in _Timer_Proc ()
> > > > #2 0x4043c04d in ?? () from /usr/lib/libglib-1.2.so.0
> > > > #3 0x4043b186 in ?? () from /usr/lib/libglib-1.2.so.0
> > > > #4 0x4043b751 in ?? () from /usr/lib/libglib-1.2.so.0
> > > > #5 0x4043b8f1 in ?? () from /usr/lib/libglib-1.2.so.0
> > > > #6 0x40240669 in ?? () from /usr/lib/libgtk-1.2.so.0
> > > > #7 0x80a0a35 in AP_UnixGnomeApp::main ()
> > > > #8 0x80a082b in main ()
> > > > #9 0x4051e9cb in ?? () from /lib/libc.so.6
> > > > (gdb)
> > > >
> > > > I get similar results after attaching to a process using ddd.
> > > >
> > > > And here's output from a ABI_OPT_DEBUG=1 build up until its death:
> > > >
> > > > [...]
> > > > DEBUG: fb_LineBreaker.cpp:162 tab run: p=0x1 type=0 leader=27 height=0
> > > > width=0 offset=1 length=140663096
> > > > DEBUG: tabstop: unknown tab stop type [L]
> > > > DEBUG: fb_LineBreaker.cpp:162 tab run: p=0x1 type=0 leader=27 height=0
> > > > width=0 offset=1 length=140664728
> > > > DEBUG: tabstop: unknown tab stop type [L]
> > > > DEBUG: fb_LineBreaker.cpp:162 tab run: p=0x1 type=0 leader=27 height=0
> > > > width=0 offset=1 length=140666400
> > > > DEBUG: tabstop: unknown tab stop type [L]
> > > > DEBUG: fb_LineBreaker.cpp:162 tab run: p=0x1 type=0 leader=27 height=0
> > > > width=0 offset=1 length=140668032
> > > > DEBUG: tabstop: unknown tab stop type [L]
> > > > DEBUG: fb_LineBreaker.cpp:162 tab run: p=0x1 type=0 leader=27 height=0
> > > > width=0 offset=1 length=140669752
> > > > DEBUG: tabstop: unknown tab stop type [L]
> > > > DEBUG: tabstop: unknown tab stop type [L]
> > > > DEBUG: Insertion Point has moved before erasing
> > > > DEBUG: fv_View::draw() called with zero drawing area.
> > > > DEBUG: fv_View::draw() called with zero drawing area.
> > > > DEBUG: fv_View::draw() called with zero drawing area.
> > > > DEBUG: ut_unixTimer.cpp: timer destructor
> > > > DEBUG: ut_unixTimer.cpp: timer destructor
> > > > DEBUG: ut_unixTimer.cpp: timer destructor
> > > >
> > > > I wish I had more time in my schedule and I'd do some poking about until
> > > > I found out what was going on, but I don't, so I thought I'd send this
> > > > info on.
> > > >
> > > > --
> > > > David Schmitz
> > > > Please allow me to introduce myself:
> > > > I'm a man of wealth and taste.
> > > > --
> > > > http://www.ecsd.com/~david
> > > >
> > > >
> > > >
> > >
> > >
> >
> > -------------------------------------------------------------
> > Thomas (toe-mah) Fletcher QNX Software Systems
> > thomasf@qnx.com Neutrino Development Group
> > (613)-591-0931 http://www.qnx.com/~thomasf
> >
> >
> >
>
-------------------------------------------------------------
Thomas (toe-mah) Fletcher QNX Software Systems
thomasf@qnx.com Neutrino Development Group
(613)-591-0931 http://www.qnx.com/~thomasf
This archive was generated by hypermail 2b25 : Fri Oct 27 2000 - 11:25:49 CDT