* How to get this debugged (pressing g fails)
@ 2013-09-26 0:01 Harry Putnam
2013-09-26 0:50 ` Katsumi Yamaoka
0 siblings, 1 reply; 6+ messages in thread
From: Harry Putnam @ 2013-09-26 0:01 UTC (permalink / raw)
To: ding
I've been ignoring this for a very long time, but I need to fix it.
Whenever I press g in group buffer to get new news it starts to work
but then ends up failing. All I catch with debugger turned on is:
Debugger entered: nil
gnus-group-get-new-news(nil)
call-interactively(gnus-group-get-new-news nil nil)
------- --------- ---=--- --------- --------
This has stayed with me for several mnths and several upgrade pulls of
gnus source code for magnus.
I really don't have a clue how to determine what is causing it.
Obviously not a general problem and just as obviously its in my
environment somehow. But where to look, and how to look?
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: How to get this debugged (pressing g fails)
2013-09-26 0:01 How to get this debugged (pressing g fails) Harry Putnam
@ 2013-09-26 0:50 ` Katsumi Yamaoka
2013-09-26 20:10 ` Harry Putnam
0 siblings, 1 reply; 6+ messages in thread
From: Katsumi Yamaoka @ 2013-09-26 0:50 UTC (permalink / raw)
To: ding
Harry Putnam wrote:
> I've been ignoring this for a very long time, but I need to fix it.
> Whenever I press g in group buffer to get new news it starts to work
> but then ends up failing. All I catch with debugger turned on is:
> Debugger entered: nil
> gnus-group-get-new-news(nil)
> call-interactively(gnus-group-get-new-news nil nil)
> ------- --------- ---=--- --------- --------
> This has stayed with me for several mnths and several upgrade pulls of
> gnus source code for magnus.
> I really don't have a clue how to determine what is causing it.
> Obviously not a general problem and just as obviously its in my
> environment somehow. But where to look, and how to look?
Type `C-]' to exit the debugger.
M-x load-library RET gnus-group.el RET
(Note: it should be .el, not .elc)
Type `g'
If you get a byte-code in the backtrace, load another .el file
and do it again. Where "another .el file" is the module that
provides the function expressed as a byte-code in the backtrace.
^ permalink raw reply [flat|nested] 6+ messages in thread* Re: How to get this debugged (pressing g fails)
2013-09-26 0:50 ` Katsumi Yamaoka
@ 2013-09-26 20:10 ` Harry Putnam
2013-09-26 22:50 ` Katsumi Yamaoka
0 siblings, 1 reply; 6+ messages in thread
From: Harry Putnam @ 2013-09-26 20:10 UTC (permalink / raw)
To: ding
Katsumi Yamaoka <yamaoka@jpl.org> writes:
Harry Wrote:
>> I really don't have a clue how to determine what is causing it.
>> Obviously not a general problem and just as obviously its in my
>> environment somehow. But where to look, and how to look?
KatsumiY replied:
> Type `C-]' to exit the debugger.
> M-x load-library RET gnus-group.el RET
> (Note: it should be .el, not .elc)
> Type `g'
> If you get a byte-code in the backtrace, load another .el file
> and do it again. Where "another .el file" is the module that
> provides the function expressed as a byte-code in the backtrace.
Thanks for the input. I think I followed the directions closely but
didn't get anything better when I pressed 'g'.
After loading gnus-group.el and pressing 'g' I just get
the same exact debugger output:
Debugger entered: nil
gnus-group-get-new-news(nil)
call-interactively(gnus-group-get-new-news nil nil)
Maybe the bit from Messages buffer will help... Going to debugger
always happens after scanning nndraft active file.
from Messages buffer
,----
| Checking new news...
| nnimap read 2k from imap.gmail.com
| Reading active file via nnml...
| Reading incoming mail from directory...
| Wrote /home/reader/Mail/mail_cron_tr/30553
| Wrote /home/reader/Mail/mail_rsnap_tr/13838
| Reading incoming mail from file...
| nnml: Reading incoming mail (2 new)...done
| Reading active file via nnml...done
| Reading active file from archive via nnfolder...done
| Reading active file via nndraft...done
| Gnus timed out.
| Entering debugger...
`----
^ permalink raw reply [flat|nested] 6+ messages in thread* Re: How to get this debugged (pressing g fails)
2013-09-26 20:10 ` Harry Putnam
@ 2013-09-26 22:50 ` Katsumi Yamaoka
2013-09-27 21:23 ` Harry Putnam
0 siblings, 1 reply; 6+ messages in thread
From: Katsumi Yamaoka @ 2013-09-26 22:50 UTC (permalink / raw)
To: ding
Harry Putnam wrote:
> After loading gnus-group.el and pressing 'g' I just get
> the same exact debugger output:
> Debugger entered: nil
> gnus-group-get-new-news(nil)
> call-interactively(gnus-group-get-new-news nil nil)
Uhm, I have no idea of how such an taciturn message is made.
> Maybe the bit from Messages buffer will help... Going to debugger
> always happens after scanning nndraft active file.
> from Messages buffer
,----
| Checking new news...
| nnimap read 2k from imap.gmail.com
| Reading active file via nnml...
| Reading incoming mail from directory...
| Wrote /home/reader/Mail/mail_cron_tr/30553
| Wrote /home/reader/Mail/mail_rsnap_tr/13838
| Reading incoming mail from file...
| nnml: Reading incoming mail (2 new)...done
| Reading active file via nnml...done
| Reading active file from archive via nnfolder...done
| Reading active file via nndraft...done
| Gnus timed out.
^^^^^^^^^^^^^^
| Entering debugger...
`----
Grep doesn't hit such a words combination in the Gnus source or
the Emacs source, but Google does. For instance, bitbucket[1]
shows this:
(defadvice gnus-group-get-new-news (around gnus-timeout activate)
"Timeout for Gnus."
(with-timeout
(5 (message "Gnus timed out.") (debug))
ad-do-it))
Do you have the one like that in your ~/.gnus.el file? If so,
too small timeout seconds (5 in that case) may cause the problem.
[1] <https://bitbucket.org/kindahero/emacsd/src/9a4c7b1e85a3ee9e80ca53f32260a6bc36e90f8a/init-gnus.el>
^ permalink raw reply [flat|nested] 6+ messages in thread* Re: How to get this debugged (pressing g fails)
2013-09-26 22:50 ` Katsumi Yamaoka
@ 2013-09-27 21:23 ` Harry Putnam
2013-10-01 14:56 ` Harry Putnam
0 siblings, 1 reply; 6+ messages in thread
From: Harry Putnam @ 2013-09-27 21:23 UTC (permalink / raw)
To: ding
Katsumi Yamaoka <yamaoka@jpl.org> writes:
[...]
>> from Messages buffer
> ,----
> | Checking new news...
> | nnimap read 2k from imap.gmail.com
> | Reading active file via nnml...
> | Reading incoming mail from directory...
> | Wrote /home/reader/Mail/mail_cron_tr/30553
> | Wrote /home/reader/Mail/mail_rsnap_tr/13838
> | Reading incoming mail from file...
> | nnml: Reading incoming mail (2 new)...done
> | Reading active file via nnml...done
> | Reading active file from archive via nnfolder...done
> | Reading active file via nndraft...done
> | Gnus timed out.
> ^^^^^^^^^^^^^^
> | Entering debugger...
> `----
>
> Grep doesn't hit such a words combination in the Gnus source or
> the Emacs source, but Google does. For instance, bitbucket[1]
> shows this:
>
> (defadvice gnus-group-get-new-news (around gnus-timeout activate)
> "Timeout for Gnus."
> (with-timeout
> (5 (message "Gnus timed out.") (debug))
> ad-do-it))
>
> Do you have the one like that in your ~/.gnus.el file? If so,
> too small timeout seconds (5 in that case) may cause the problem.
>
> [1] <https://bitbucket.org/kindahero/emacsd/src/9a4c7b1e85a3ee9e80ca53f32260a6bc36e90f8a/init-gnus.el>
Haa, you got it Katsumi. Now I remember a good while back being
disgusted with long stalls from gnus and so thought I was being very
clever by putting that code in .gnus, making gnus fail and tell me
why. Instead of just setting there endlessly.
Over time I forgot all about it.
Thank you for investigating and hitting pay dirt.
A simple 5 second increase, up to 10 seconds solved the problem and
maybe I'll even remember it for a while now.
But more than anything, thanks for letting me watch HOW you
investigated the few clues I provided.
It all looks very simple seeing you do it, but I would probably never
have thought to follow the clues so well.
The technique is worth a lot. And I expect keeping it in mind when
doing other debugging chores (even in other scripting or languages)
will stand me in good stead. Again, thanks.
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: How to get this debugged (pressing g fails)
2013-09-27 21:23 ` Harry Putnam
@ 2013-10-01 14:56 ` Harry Putnam
0 siblings, 0 replies; 6+ messages in thread
From: Harry Putnam @ 2013-10-01 14:56 UTC (permalink / raw)
To: ding
Harry Putnam <reader@newsguy.com> writes:
[...]
Katsumi wrote:
>> Grep doesn't hit such a words combination in the Gnus source or
>> the Emacs source, but Google does. For instance, bitbucket[1]
>> shows this:
>>
>> (defadvice gnus-group-get-new-news (around gnus-timeout activate)
>> "Timeout for Gnus."
>> (with-timeout
>> (5 (message "Gnus timed out.") (debug))
>> ad-do-it))
>>
>> Do you have the one like that in your ~/.gnus.el file? If so,
>> too small timeout seconds (5 in that case) may cause the problem.
>>
>> [1] <https://bitbucket.org/kindahero/emacsd/src/9a4c7b1e85a3ee9e80ca53f32260a6bc36e90f8a/init-gnus.el>
Harry responded:
> Haa, you got it Katsumi. Now I remember a good while back being
> disgusted with long stalls from gnus and so thought I was being very
> clever by putting that code in .gnus, making gnus fail and tell me
> why. Instead of just setting there endlessly.
[...]
I may have been overly optimistic above.
Increasing the timeout seemed to do the job at first but after a few
refreshes it needed to be increased repeatedly.
Finally, after commenting that timeout code, I see why I'd put it
there long ago. I was experiencing endless waits when pressing 'g'.
I've just been working around the problem for so long... I forgot.
What happens is: calling gnus-group-get-new-news leads to a never
ending wait that never finishes.
All my nnimap, nnml groups go thru the process ending with nndrafts.
From there is goes to the nntp groups... once that starts its going to
just set there to eternity until I hit C-g.
I don't believe it is a connection issue because a manual refresh of
individual nntp (`gnus-group-get-new-news-this-group') groups finishes
with only a small pause.
Further, a restart happens in a normal amount of time which also calls
that code gnus-group-get-new-news (I think).
So in summary: I
I can refresh all groups by closing and restarting gnus in a normal
amount of time.
I can refresh groups individually or even en-masse by process marking
and pressing M-g (gnus-group-get-new-news-this-group)
However pressing 'g' in a group buffer ( `gnus-group-get-new-news' )
leads to a never ending process that only stops with C-g
Watching the nntp-log buffer when I press C-g to terminate the wait
I see it stopped at the first nntp newsguy group. So I'm thinking
there is some cantankerous newsguy group.
However, Pressing A M <RET> newsguy <RET> to find all newsguy groups,
then process marking and pressing M-g
(`gnus-group-get-new-news-this-group'), they all get processed with
only a brief wait... maybe 10 seconds. So doesn't seem to be a
problem newsguy group causing the trouble
------- --------- ---=--- --------- --------
I suspect the trouble is caused by something I've done but not sure
how get to root of the trouble.
How can I determine what gnus is doing during that never ending wait
produced by pressing 'g' (`gnus-group-get-new-news') in group buffer?
^ permalink raw reply [flat|nested] 6+ messages in thread
end of thread, other threads:[~2013-10-01 14:56 UTC | newest]
Thread overview: 6+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2013-09-26 0:01 How to get this debugged (pressing g fails) Harry Putnam
2013-09-26 0:50 ` Katsumi Yamaoka
2013-09-26 20:10 ` Harry Putnam
2013-09-26 22:50 ` Katsumi Yamaoka
2013-09-27 21:23 ` Harry Putnam
2013-10-01 14:56 ` Harry Putnam
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).