Subject: debugging pine

From: Joel Boonstra <[email-masked]>
Date: Mon, 8 Apr 2002 17:38:20 -0400 (EDT)

Hey folks,

How can I discover what exactly Pine is doing while it hangs, or slows
down?  I find that *very* frequently I wait for pine to do something.
I'm using Eduardo's fancy threads interface, but using the not-recommended
'force-local-threading' option, as my IMAP server doesn't seem to thread
properly.  So I figure it's just pine trying to compute threads.

But how do I know for sure?  Do I need to run pine through gdb?  I'm
willing to do this, but it's been about 3 years since I used gdb for
anything useful, so I'll have to brush up on that a little.

The reason I'm curious is that I was just on a different LAN, and pine was
pretty zippy then.  Odd, since it was hotel LAN, vs. my work LAN (which is
incredibly fast, and in the next room over from the mail server).

So, any insight would help.  Basically the behavior that I'm seeing is
inconsistent.  While performing various operations, (compose, select a
thread, aggregate commands, single commands, postpone, etc...) pine will
just hang for awhile before carrying out the task.  My pine screen will
freeze, and no keyboard input will happen.  Then, after awhile (a few
seconds) it'll perform whatever action it was trying to do, and then
whatever keyboard input I sent during that time.

A few seconds doesn't sound like much, but it sure does get annoying after
awhile, especially when just quick trying to do something.

Anyway, thanks,

-- 
[ joel boonstra | [email-masked] ]

-- 
-----------------------------------------------------------------
 For information about this mailing list, and its archives, see: 
 http://www.washington.edu/pine/pine-info/
-----------------------------------------------------------------

---

From: Jacob Morzinski <[email-masked]>
Date: Mon, 8 Apr 2002 17:58:58 -0400 (EDT)

> down?  I find that *very* frequently I wait for pine to do something.

If you run pine with the "-d 9" command flag, you will get the highest
level of debugging output.  The test that I did appeared to include
timestamps for most logfile entries.  I don't know if you need "9" for
the timestamps or if a less-verbose debuglevel would also give
timestamps.

The procedure I would follow would be to run pine with timestamps in
the debug log, and compare the debug log of a "slow" pine against the
debug log of a "fast" different pine.  	I don't expect it to be a
miracle solution, but it may show you where to start examing the
source or where to start debugging.

-- 
 Jacob Morzinski                                [email-masked]