Tracking down a gnus-summary-move-article problem.

Tracking down a gnus-summary-move-article problem.

[Rob Browning]

I've reported this to gnus-bug, but I wanted to see if anyone else
here had see this or had suggestions for things I could try to track
this down.

I had a problem a while back with gnus-summary-move-article.  It would
fail when called on an article just after a followup.  After poking
around in the source, I realized it was a configuration problem on my
end (message-directory was set wrong given my other variables).  I
fixed that, and then gnus-summary-move-article would get a little
further before failing in a much more serious manner.

I can't give a backtrace for the error because for some reason the
failure both doesn't give a backtrace, and disables debug-on-error,
but here's the relevant bit of the message buffer.

  Opening nnml server on rlb...
  Moving to nnml+rlb:gnucash: (35369)...
  Loading gnus-dup...
  Loading gnus-dup...done
  Wrote /home/rlb/.gnus/mail/incoming/gnucash/3467
  Opening nnml server on rlb+nnml+rlb:gnucash...
  No such group: gnucash
  nnml+rlb:gnucash error: No such group: gnucash

After this, if I quit gnus and restart, all of the nnml+rlb groups in
the group buffer will have a "*" for their message counts, and I can't
enter any of them:

  Signaling: (error "Couldn't request group nnml+rlb:guile: No such group: guile")
    signal(error ("Couldn't request group nnml+rlb:guile: No such group: guile"))
    error("Couldn't request group %s: %s" "nnml+rlb:guile" "No such group: guile")
    gnus-select-newsgroup("nnml+rlb:guile" nil nil)
    gnus-summary-read-group-1("nnml+rlb:guile" nil t nil nil nil)
    gnus-summary-read-group("nnml+rlb:guile" nil t nil nil nil nil)
    gnus-group-read-group(nil t)
    gnus-group-select-group(nil)
    gnus-topic-select-group(nil)
    call-interactively(gnus-topic-select-group)

The problem can be fixed by rebuilding the nov databases, but will
occur again next time I trigger the error.

Thanks

-- 
Rob Browning <rlb@cs.utexas.edu> PGP=E80E0D04F521A094 532B97F5D64E3930

gnus-summary-move-article problem may be a .newsrc.eld problem.

[Rob Browning]

[-- Attachment #1: Type: text/plain, Size: 4642 bytes --]

Pterodactyl Gnus v0.98
GNU Emacs 20.4.2 (i386-debian-linux-gnu, X toolkit)
 of Fri Nov 12 1999 on raven

OK, after a lot of poking around using a dummy account, I figured out
what was causing the summary "B m" crashes that trashed the server
active file and fixed it.  I'm not sure that my fix isn't just masking
some other bug, but it seems to work.  My hypothesis is that if you're
not careful, you can get a server representation "mismatch" in your
newsrc.eld between two groups that belong to the same server that
causes gnus to think they're from different servers and then to call
code that trashes the active file.

Just to review, the error occurred whenever I entered my main mailbox,
followed up to an article via "F", then unmarked the article (via
"M-u"), and then tried to move it to another group (via "B m").  At
that point gnus would announce an error and the active file would be
truncated.

After poking around in the source and annotating a bunch of it with
"message" statements, I got the impression that the problem might be
that my newsrc.eld had some groups that looked like this,

  ("nnml+rlb:inbox"
   2 (...)
   (nnml "rlb"
         (nnml-directory "~/.gnus/mail/incoming")
         (nnml-active-file "~/.gnus/mail/incoming/active")))

  ("nnml+rlb:gnucash"
   2 (...)
   (nnml "rlb"
         (nnml-directory "~/.gnus/mail/incoming")
         (nnml-active-file "~/.gnus/mail/incoming/active")))

and others that looked like this

  ("nnml+rlb:sw.g-wrap" 2 nil nil "nnml:rlb")

What I found out while playing with the dummy account was that 99% of
the time, all new mail groups were being created with the server set
to "nnml:somename" rather than being set to the whole server
definition.  By "whole server definition", I mean the expanded
definition of the server that included all the parameters explicitly.

For some reason when a group used the "expanded" server definition a
move after a followup and unmark would crash.  If instead, all the
groups used the "nnml:somename" representation of the server, then
there was no problem.

As a test I bravely manually edited my real newsrc.eld file to change
all my nnml+rlb groups to use the "nnml:somename" approach rather than
the expanded approach, and the "move after followup" crash vanished.

One question I have is, is the "expanded" server format prohibited for
groups with the same server?  If not, then I suppose there's probably
some other bug still lurking that I only masked.

FWIW most of the time, new groups are added with the "nnml:somename"
server spec format, not the expanded format, but if you follow the
instructions below, you can cause the group definition to use the
"expanded" format that causes the problems.  There may be other ways,
but I know that this one works:

  User input is in double quotes.  I know this works if you've never run
  gnus (I'm not sure that's required), if the primary (news) server is
  unavailable, and if there is some mail waiting for you in your system
  mail spool.

    1) Run emacs.
    2) "M-x gnus"
    3) Press "y" to continue after the error.
    4) "^"
    5) Enter your nnml server
    6) Press "u" to subscribe to the new primary group.
    7) Exit all the way back to the *Groups* buffer.
    8) "s"

If you look at the newsrc.eld file after this, you'll see that the
main inbox's server is in "expanded" format.

If after step 3 above, you just use "U" from the *Groups* buffer to
subscribe to the new group rather than going into the server buffer
with "^", then you won't get the expanded format for the server
definition, you'll get just "nnml:mail.misc".  The same is true for
the other ways I tried adding the new group(s) (i.e. "F", "A l 3", "S
l 2", etc.).

I think there was actually some evidence in the gnus error messages
about the problem.  It would say:

Rob Browning <rlb@cs.utexas.edu> writes:

>   Opening nnml server on rlb...
>   Moving to nnml+rlb:gnucash: (35369)...
>   Loading gnus-dup...
>   Loading gnus-dup...done
>   Wrote /home/rlb/.gnus/mail/incoming/gnucash/3467
>   Opening nnml server on rlb+nnml+rlb:gnucash...
>   No such group: gnucash
>   nnml+rlb:gnucash error: No such group: gnucash

Note the server name "rlb+nnml+rlb:gnucash" I believe that's an
incorrect server "parent/child" relationship that's brought on by the
problem in my newsrc.eld.  In cases where the newsrc.eld didn't have
the "expanded" server definitions, nnoo-change-server was never
called.  This observation is certainly a guess though.  I certainly
don't fully understand the code in there yet.

Anyway, I hope this helps, and if you need any more information, just
let me know.

Thanks


[-- Attachment #2: User settings --]
[-- Type: application/x-emacs-lisp, Size: 8943 bytes --]

[-- Attachment #3: Type: text/plain, Size: 76 bytes --]


-- 
Rob Browning <rlb@cs.utexas.edu> PGP=E80E0D04F521A094 532B97F5D64E3930

Re: gnus-summary-move-article problem may be a .newsrc.eld problem.

[Simon Josefsson]

Rob Browning <rlb@cs.utexas.edu> writes:

> One question I have is, is the "expanded" server format prohibited for
> groups with the same server?

No, it's ok. I believe.

>     1) Run emacs.
>     2) "M-x gnus"
>     3) Press "y" to continue after the error.
>     4) "^"
>     5) Enter your nnml server
>     6) Press "u" to subscribe to the new primary group.
>     7) Exit all the way back to the *Groups* buffer.
>     8) "s"
> 
> If you look at the newsrc.eld file after this, you'll see that the
> main inbox's server is in "expanded" format.

I think I've fixed this a while ago, can you try Gnus from cvs?

> If after step 3 above, you just use "U" from the *Groups* buffer to
> subscribe to the new group rather than going into the server buffer
> with "^", then you won't get the expanded format for the server
> definition, you'll get just "nnml:mail.misc".  The same is true for
> the other ways I tried adding the new group(s) (i.e. "F", "A l 3", "S
> l 2", etc.).

Good.

> Anyway, I hope this helps, and if you need any more information, just
> let me know.

Hm, exactly in what way was the .newsrc file "trashed"?  How did it
manifest itself? Were you able to track it back to the code that did
the actual trashing?

The "method in expanded form" -> "short form" conversion should not
solve any bugs, it's only a feature. If Gnus trashes .newsrc.eld when
you have methods in expanded form, there's bug somewhere.

Re: gnus-summary-move-article problem may be a .newsrc.eld problem.

[Rob Browning]

Simon Josefsson <jas@pdc.kth.se> writes:

> I think I've fixed this a while ago, can you try Gnus from cvs?

OK, but I'll have to go find the info on checking out the CVS tree.  I
thought I looked for it on the web pages a little while back, but
didn't see it.  I'll poke around again.

> > Anyway, I hope this helps, and if you need any more information, just
> > let me know.
> 
> Hm, exactly in what way was the .newsrc file "trashed"?  How did it
> manifest itself? Were you able to track it back to the code that did
> the actual trashing?

The .newsrc.eld file was never "trashed".  It just had both server
forms in it.  What was happening was that whenever I was trying to "B
m" from one group to another after an "F" (followup) and a "U" unmark,
I'd get the error I reported a while back and the active file would be
truncated to zero size.

If you like I can use my dummy account to try and generate a set of
instructions along with a sample .newsrc and .emacs that'll cause the
crash.  That should be pretty easy, though I should probably check CVS
first.

> The "method in expanded form" -> "short form" conversion should not
> solve any bugs, it's only a feature. If Gnus trashes .newsrc.eld when
> you have methods in expanded form, there's bug somewhere.

OK.  So can the outgoing groups (misc-mail and misc-news) use the more
abbreviated format?

Thanks.

-- 
Rob Browning <rlb@cs.utexas.edu> PGP=E80E0D04F521A094 532B97F5D64E3930

Re: gnus-summary-move-article problem may be a .newsrc.eld problem.

[Lars Magne Ingebrigtsen]

Rob Browning <rlb@cs.utexas.edu> writes:

> After poking around in the source and annotating a bunch of it with
> "message" statements, I got the impression that the problem might be
> that my newsrc.eld had some groups that looked like this,
> 
>   ("nnml+rlb:inbox"
>    2 (...)
>    (nnml "rlb"
>          (nnml-directory "~/.gnus/mail/incoming")
>          (nnml-active-file "~/.gnus/mail/incoming/active")))
> 
>   ("nnml+rlb:gnucash"
>    2 (...)
>    (nnml "rlb"
>          (nnml-directory "~/.gnus/mail/incoming")
>          (nnml-active-file "~/.gnus/mail/incoming/active")))
> 
> and others that looked like this
> 
>   ("nnml+rlb:sw.g-wrap" 2 nil nil "nnml:rlb")

[...]

> One question I have is, is the "expanded" server format prohibited for
> groups with the same server?  If not, then I suppose there's probably
> some other bug still lurking that I only masked.

It should not be -- Gnus uses `gnus-server-equal' to see whether two
servers are equal or not, and it should understand both formats.

What does

(gnus-server-equal
 '(nnml "rlb"
         (nnml-directory "~/.gnus/mail/incoming")
         (nnml-active-file "~/.gnus/mail/incoming/active"))
 "nnml:rlb")

evaluate to?

-- 
(domestic pets only, the antidote for overdose, milk.)
   larsi@gnus.org * Lars Magne Ingebrigtsen