"End of file during parsing"

"End of file during parsing"

[H. Vdisdnen]

gnus-5.4.53 sometimes says "End of file during parsing" while in
*Group* buffer and retrieving some newsgroup.

Error does not generate a backtrace, and generally I can read
the group with SPACE command if I issue that command many times.
Gnus gives the error message maybe half a dozen times and then
reads the group.

Any ideas?

Re: "end of file during parsing"

[Kevin Greiner]

inlined


---------- Original Message ----------------------------------
From: Gaute B Strokkenes <gs234@srcf.ucam.org>
Date: Sun, 08 Jan 2006 18:50:09 +0100

>On  8 jan 2006, kevin.greiner@compsol.cc wrote:
>
>> 1) Append a ")" to close the list then add the digit "1" to 
inform 
>> the agent that the list is uncompressed.  The end of your file 
>> should look something like
>>
>> (357190) 
>> (357191) 
>> (357192))
>> 1
>
>Thanks for your advice.  I followed it and everything seems to be
>working fine again.  Examining .agentview after starting gnus and
>getting new news there is no change in the file, except for the
>addition of several new entries below the old ones.
>
>Out of curiosity, am I likely to experience any kind of 
corruption or
>odd behaviour due to this?  Or is it entirely safe?

It depends on which file has been truncated.  If we're just 
talking about .agentview, gnus will forget that you've already 
downloaded some articles.  That's annoying as you have to download 
them again but usually not a failure.  Of course, you could run 
gnus-agent-regenerate-group to "repair" the list as it will insert 
the missing entries (it scans your harddrive for all downloaded 
articles then updates the list to match).  That would offer 
recovery but you've probably past that point by now.

>
>> 2) There's no cause to find.  The entire list, including your 
>> missing parenthesis, is printed by a single call to princ.
>
>Well, I agree that this would be hard to find; I looked in the 
lisp
>manual for variables controlling the lisp printer for likely 
culprits
>but found nothing that could explain this failure mode.  
Nevertheless,
>things like this don't happen by themselves.  But I suppose the
>problem could be deep in emacs somewhere, far beneath gnus.

I can offer a couple, 1) your disk was full, or 2) you killed the 
emacs process before gnus completed its shutdown (I've personally 
done the later by halting my laptop too soon).  However, neither 
really offers any help preventing a repeat.

Kevin 

________________________________________________________________
Sent via the EV1 webmail system at mail.ev1.net


 
                   

Re: "end of file during parsing"

[Gaute B Strokkenes]

On  8 jan 2006, kevin.greiner@compsol.cc wrote:

> 1) Append a ")" to close the list then add the digit "1" to inform 
> the agent that the list is uncompressed.  The end of your file 
> should look something like
>
> (357190) 
> (357191) 
> (357192))
> 1

Thanks for your advice.  I followed it and everything seems to be
working fine again.  Examining .agentview after starting gnus and
getting new news there is no change in the file, except for the
addition of several new entries below the old ones.

Out of curiosity, am I likely to experience any kind of corruption or
odd behaviour due to this?  Or is it entirely safe?

> 2) There's no cause to find.  The entire list, including your 
> missing parenthesis, is printed by a single call to princ.

Well, I agree that this would be hard to find; I looked in the lisp
manual for variables controlling the lisp printer for likely culprits
but found nothing that could explain this failure mode.  Nevertheless,
things like this don't happen by themselves.  But I suppose the
problem could be deep in emacs somewhere, far beneath gnus.

-- 
Gaute Strokkenes                        http://www.srcf.ucam.org/~gs234/
I always liked FLAG DAY!!

Re: "end of file during parsing"

[Kevin Greiner]

1) Append a ")" to close the list then add the digit "1" to inform 
the agent that the list is uncompressed.  The end of your file 
should look something like

(357190) 
(357191) 
(357192))
1

2) There's no cause to find.  The entire list, including your 
missing parenthesis, is printed by a single call to princ.

Kevin


---------- Original Message ----------------------------------
From: Gaute B Strokkenes <gs234@srcf.ucam.org>
>So, my questions are:
>
>1) How can I fix this, hopefully with minimal disruption?  I am
>   tempted to simply add a ")" at the end but I am fearful of the
>   results.
>
>2) How would I go about finding the cause of this problem in the 
gnus
>   source?
 

________________________________________________________________
Sent via the EV1 webmail system at mail.ev1.net


 
                   

Re: "end of file during parsing"

[Gaute B Strokkenes]

On 17 des 2005, dave@boost-consulting.com wrote:

> When trying to start Gnus, now, I get a dreaded "end of file during
> parsing" message, after it has connected to my servers and got all the
> group information.  My *Group* buffer is completely unpopulated and
> none of my keystrokes work.  Enabling "enter debugger on error" gets
> me nowhere.  Can anyone help me?  I don't know where to begin.

I recently started having a similar problem, and tried the same
remedies as David, to little avail.  (In my case this happens during
startup and I don't even get a *Group* buffer.) However, I've gotten a
little bit further.

Using strace on emacs reveals that the last file opened before the
error is 

  ~/News/agent/nntp/news.gmane.org/gmane/linux/kernel/.agentview

and as it turns out removing the gmane entry from
gnus-secondary-servers solves the problem, at the obvious cost of my
not being able to access any of my game groups.

Now the emacs lisp manual indicates that this error is somehow related
to the lisp reader, so I examined the file manually and wrote a small
script that compared the relative numbers of "(" and ")" in a file and
ran it on all the .agentview in my ~/News hierarchy.  As it turns out
the file mentioned above is the only .agentview file that does not
contain an equal number of "(" and ")" characters.  It has a single
"(" too much,, which explains the lisp reader error.

The linux kernel mailing list is a very large and busy list, and at
the time this happened there were iirc well over 100,000 unread
messages in that group, along with many ticked messages, some of the
really old.

I'm guessing that somehow this file got truncated on writing.  How, I
have no idea.  Here's an excerpt:

--8<--
(357183)
(357184)
(357185)
(357186)
(357187)
(357188)
(357189)
(357190)
(357191)
(357192)
--8<--

That's the ten last lines of the file, after a replace-string ") " ->
")^J" has been performed for legibility.  However, there is no
trailing newline.

So, my questions are:

1) How can I fix this, hopefully with minimal disruption?  I am
   tempted to simply add a ")" at the end but I am fearful of the
   results.

2) How would I go about finding the cause of this problem in the gnus
   source?

-- 
Gaute Strokkenes                        http://www.srcf.ucam.org/~gs234/
Yow!  Now I get to think about all the BAD THINGS I did to a BOWLING BALL
 when I was in JUNIOR HIGH SCHOOL!

"end of file during parsing"

[David Abrahams]

When trying to start Gnus, now, I get a dreaded "end of file during
parsing" message, after it has connected to my servers and got all the
group information.  My *Group* buffer is completely unpopulated and
none of my keystrokes work.  Enabling "enter debugger on error" gets
me nowhere.  Can anyone help me?  I don't know where to begin.

Thanks.
-- 
Dave Abrahams
Boost Consulting
www.boost-consulting.com