End of file while generating loaddefs.el

End of file while generating loaddefs.el

[Eli Zaretskii]

  $ cd lisp && make autoloads
  Directories for loaddefs: . ./calc ./calendar ./cedet ./cedet/ede ./cedet/semantic ./cedet/semantic/analyze ./cedet/semantic/bovine ./cedet/semantic/decorate ./cedet/semantic/symref ./cedet/semantic/wisent ./cedet/srecode ./emacs-lisp ./emulation ./erc ./eshell ./gnus ./international ./language ./leim ./leim/ja-dic ./leim/quail ./mail ./mh-e ./net ./nxml ./org ./play ./progmodes ./textmodes ./url ./vc
    GEN      loaddefs.el
  End of file during parsing  <<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<

This started happening on the emacs-25 branch 2 days ago.  Does anyone
else see this?

Re: End of file while generating loaddefs.el

[martin rudalics]

 > This started happening on the emacs-25 branch 2 days ago.  Does anyone
 > else see this?

Here I see

...
Directories for loaddefs: . ./calc ./calendar ./cedet ./cedet/ede ./cedet/semantic ./cedet/semantic/analyze ./cedet/semantic/bovine ./cedet/semantic/decorate ./cedet/semantic/symref ./cedet/semantic/wisent ./cedet/srecode ./emacs-lisp ./emulation ./erc ./eshell ./gnus ./international ./language ./leim ./leim/ja-dic ./leim/quail ./mail ./mh-e ./net ./nxml ./org ./play ./progmodes ./textmodes ./url ./vc
   GEN      loaddefs.el
Making generated-autoload-file local to  *autoload-file* while let-bound!

Exception 0xc0000005 at this address:
77c17026

Backtrace:
0115011b

This application has requested the Runtime to terminate it in an unusual way.
Please contact the application's support team for more information.
make[2]: *** [loaddefs.el] Error 3
make[2]: Leaving directory `/c/emacs-git/next/lisp'
make[1]: *** [../lisp/loaddefs.el] Error 2
make[1]: Leaving directory `/c/emacs-git/next/src'
make: *** [src] Error 2
...

so this should be the same issue.

martin

Re: End of file while generating loaddefs.el

[Eli Zaretskii]

> Date: Wed, 18 Nov 2015 08:50:51 +0100
> From: martin rudalics <rudalics@gmx.at>
> 
>  > This started happening on the emacs-25 branch 2 days ago.  Does anyone
>  > else see this?
> 
> Here I see
> 
> ...
> Directories for loaddefs: . ./calc ./calendar ./cedet ./cedet/ede ./cedet/semantic ./cedet/semantic/analyze ./cedet/semantic/bovine ./cedet/semantic/decorate ./cedet/semantic/symref ./cedet/semantic/wisent ./cedet/srecode ./emacs-lisp ./emulation ./erc ./eshell ./gnus ./international ./language ./leim ./leim/ja-dic ./leim/quail ./mail ./mh-e ./net ./nxml ./org ./play ./progmodes ./textmodes ./url ./vc
>    GEN      loaddefs.el
> Making generated-autoload-file local to  *autoload-file* while let-bound!
> 
> Exception 0xc0000005 at this address:
> 77c17026
> 
> Backtrace:
> 0115011b
> 
> This application has requested the Runtime to terminate it in an unusual way.
> Please contact the application's support team for more information.
> make[2]: *** [loaddefs.el] Error 3

If you run this command under a debugger, what do you see in the
backtrace when Emacs crashes?

Re: End of file while generating loaddefs.el

[martin rudalics]

 > If you run this command under a debugger,

How do I do that?

 > what do you see in the
 > backtrace when Emacs crashes?

Attaching gdb to bootstrap-emacs.exe when it crashes gives

#0  0x7c911231 in ntdll!DbgUiConnectToDbg () from C:\WINDOWS\system32\ntdll.dll
#1  0x7c9607a8 in ntdll!KiIntSystemCall () from C:\WINDOWS\system32\ntdll.dll
#2  0x00000005 in ?? ()
#3  0x00000004 in ?? ()
#4  0x00000001 in ?? ()
#5  0x0498ffd0 in ?? ()
#6  0x00000000 in ?? ()

Lisp Backtrace:
"prin1" (0x82ee7c)
"autoload-insert-section-header" (0x82f008)
"update-directory-autoloads" (0x82f174)
"apply" (0x82f2dc)
"batch-update-autoloads" (0x82f48c)
"command-line-1" (0x82f608)
"command-line" (0x82f7bc)
"normal-top-level" (0x82f8d0)

martin

Re: End of file while generating loaddefs.el

[Eli Zaretskii]

> Date: Thu, 19 Nov 2015 09:13:01 +0100
> From: martin rudalics <rudalics@gmx.at>
> CC: emacs-devel@gnu.org
> 
>  > If you run this command under a debugger,
> 
> How do I do that?

Run "make V=1" to see the full command line of the command that fails,
then start "gdb ./emacs.exe" in the src directory, and copy/paste the
offending command line into the GDB command to run Emacs, right after
the "run" part.  Then wait until it segfaults.

>  > what do you see in the
>  > backtrace when Emacs crashes?
> 
> Attaching gdb to bootstrap-emacs.exe when it crashes gives

That's too late: when a program running not under a debugger triggers
a fatal exception, Windows invokes the global exception handler, which
in this case is installed by the MinGW startup code, so you don't see
the application stack.  When a program is being debugged, the debugger
gets the first opportunity to handle the exception, so it can display
much more information.

> Lisp Backtrace:
> "prin1" (0x82ee7c)
> "autoload-insert-section-header" (0x82f008)

Looks like some GC problem to me, as prin1 uses a temporary buffer to
produce its strings.

Re: End of file while generating loaddefs.el

[John Wiegley]

>>>>> Eli Zaretskii <eliz@gnu.org> writes:

> Run "make V=1" to see the full command line of the command that fails, then
> start "gdb ./emacs.exe" in the src directory, and copy/paste the offending
> command line into the GDB command to run Emacs, right after the "run" part.
> Then wait until it segfaults.

Nowadays GDB also supports:

    gdb --args ./emacs.exe <arguments to run with>

Then just "bt" to see the backtrace after it crashes.

John

Re: End of file while generating loaddefs.el

[martin rudalics]

 > Run "make V=1" to see the full command line of the command that fails,
 > then start "gdb ./emacs.exe" in the src directory, and copy/paste the
 > offending command line

Apparently this is

EMACSLOADPATH= '../src/bootstrap-emacs.exe' -batch --no-site-file --no-site-lisp -l autoload \
	    --eval '(setq autoload-ensure-writable t)' \
	    --eval '(setq autoload-builtin-package-versions t)' \
	    --eval '(setq generated-autoload-file (expand-file-name (unmsys--file-name "loaddefs.el")))' \
	    -f batch-update-autoloads . ./calc ./calendar ./cedet ./cedet/ede ./cedet/semantic ./cedet/semantic/analyze ./cedet/semantic/bovine ./cedet/semantic/decorate ./cedet/semantic/symref ./cedet/semantic/wisent ./cedet/srecode ./emacs-lisp ./emulation ./erc ./eshell ./gnus ./international ./language ./leim ./leim/ja-dic ./leim/quail ./mail ./mh-e ./net ./nxml ./org ./play ./progmodes ./textmodes ./url ./vc

 > into the GDB command to run Emacs, right after
 > the "run" part.  Then wait until it segfaults.

When I do that it doesn't segfault but simply produces the "End of file
during parsing" message you reported earlier.

martin

Re: End of file while generating loaddefs.el

[Eli Zaretskii]

> Date: Fri, 20 Nov 2015 09:23:10 +0100
> From: martin rudalics <rudalics@gmx.at>
> Cc: emacs-devel@gnu.org
> 
>  > into the GDB command to run Emacs, right after
>  > the "run" part.  Then wait until it segfaults.
> 
> When I do that it doesn't segfault but simply produces the "End of file
> during parsing" message you reported earlier.

Darn!  Another memory-related Heisenbug!

I guess the only way to debug this is see what happens inside prin1.
AFAIR, it uses a temporary buffer to produce the string, so this might
be due to GC or something.

Re: End of file while generating loaddefs.el

[David Kastrup]

Eli Zaretskii <eliz@gnu.org> writes:

>> Date: Fri, 20 Nov 2015 09:23:10 +0100
>> From: martin rudalics <rudalics@gmx.at>
>> Cc: emacs-devel@gnu.org
>> 
>>  > into the GDB command to run Emacs, right after
>>  > the "run" part.  Then wait until it segfaults.
>> 
>> When I do that it doesn't segfault but simply produces the "End of file
>> during parsing" message you reported earlier.
>
> Darn!  Another memory-related Heisenbug!
>
> I guess the only way to debug this is see what happens inside prin1.
> AFAIR, it uses a temporary buffer to produce the string, so this might
> be due to GC or something.

For the record: if it weren't on Windows, you could say something like

ulimit -c unlimited  # Possibly a bad idea on 64bit systems

and then run the program again from the command line.  This should make
it behave identically until crashing, producing a "core" file when doing
so.

You can then run

gdb src/emacs core   # or whatever your corresponding binary was

and then do a post-mortem debug, particularly looking at the backtrace.

-- 
David Kastrup

Re: End of file while generating loaddefs.el

[Eli Zaretskii]

> From: David Kastrup <dak@gnu.org>
> Cc: martin rudalics <rudalics@gmx.at>,  emacs-devel@gnu.org
> Date: Fri, 20 Nov 2015 10:46:55 +0100
> 
> You can then run
> 
> gdb src/emacs core   # or whatever your corresponding binary was
> 
> and then do a post-mortem debug, particularly looking at the backtrace.

Post-mortem debugging Emacs core files is a pain because you cannot
evaluate Lisp, so examining Lisp data is tedious at best, and
downright impractical at worst.

Re: End of file while generating loaddefs.el

[Eli Zaretskii]

> Date: Fri, 20 Nov 2015 10:38:37 +0200
> From: Eli Zaretskii <eliz@gnu.org>
> Cc: emacs-devel@gnu.org
> 
> I guess the only way to debug this is see what happens inside prin1.
> AFAIR, it uses a temporary buffer to produce the string, so this might
> be due to GC or something.

I don't know why prin1 crashed, but I do know why Emacs complains
about end of file: there are null bytes in the middle of loaddefs.el.
Do you have those too?

Emacs creates loaddefs.el by visiting the previous one and scanning it
for certain patterns.  Those stray null bytes interrupt a pattern, so
the result is that Emacs tries to parse an incomplete sexp, and barfs.

if you also see these null bytes, delete them so that the expected
format of the file is preserved, then re-run "make autoloads" -- it
should succeed.

I don't know how these nulls ended up in loaddefs, the only hint is
that they appear in the same place which Emacs scans when it produces
this warning:

  Making generated-autoload-file local to  *autoload-file* while let-bound

Re: End of file while generating loaddefs.el

[martin rudalics]

 > I don't know why prin1 crashed, but I do know why Emacs complains
 > about end of file: there are null bytes in the middle of loaddefs.el.
 > Do you have those too?

I suppose you mean this entry:

(autoload 'xref-find-backend "xref" "\


\(fn)" nil nil)

Do autoload cookies require a doc-string?

 > Emacs creates loaddefs.el by visiting the previous one and scanning it
 > for certain patterns.  Those stray null bytes interrupt a pattern, so
 > the result is that Emacs tries to parse an incomplete sexp, and barfs.

Why (apparently) on Windows only?

 > if you also see these null bytes, delete them so that the expected
 > format of the file is preserved, then re-run "make autoloads" -- it
 > should succeed.

I now have

(autoload 'xref-find-backend "xref" "\
Run...

\(fn)" nil nil)

instead and it ran to completion.

 > I don't know how these nulls ended up in loaddefs, the only hint is
 > that they appear in the same place which Emacs scans when it produces
 > this warning:
 >
 >    Making generated-autoload-file local to  *autoload-file* while let-bound

How did you spot that location?

martin

Re: End of file while generating loaddefs.el

[Eli Zaretskii]

> Date: Sat, 21 Nov 2015 09:33:38 +0100
> From: martin rudalics <rudalics@gmx.at>
> CC: emacs-devel@gnu.org
> 
>  > I don't know why prin1 crashed, but I do know why Emacs complains
>  > about end of file: there are null bytes in the middle of loaddefs.el.
>  > Do you have those too?
> 
> I suppose you mean this entry:
> 
> (autoload 'xref-find-backend "xref" "\
> 
> 
> \(fn)" nil nil)

The null bytes were in a different place in my case.

And anyway, what's the problem with the above?  That's what I have
here, after the problem is solved.  I also see that on GNU/Linux,
where there was no problem to begin with.

Why do you think it's this entry that was the cause of the problem?

> Do autoload cookies require a doc-string?

No, they don't require them.

>  > Emacs creates loaddefs.el by visiting the previous one and scanning it
>  > for certain patterns.  Those stray null bytes interrupt a pattern, so
>  > the result is that Emacs tries to parse an incomplete sexp, and barfs.
> 
> Why (apparently) on Windows only?

I don't know, because I have no idea what caused that in the first
place.

>  > if you also see these null bytes, delete them so that the expected
>  > format of the file is preserved, then re-run "make autoloads" -- it
>  > should succeed.
> 
> I now have
> 
> (autoload 'xref-find-backend "xref" "\
> Run...
> 
> \(fn)" nil nil)
> 
> instead and it ran to completion.

Great!  Although I don't understand what was the problem with that
spot in your case.  Were there any null bytes, anywhere?

>  > I don't know how these nulls ended up in loaddefs, the only hint is
>  > that they appear in the same place which Emacs scans when it produces
>  > this warning:
>  >
>  >    Making generated-autoload-file local to  *autoload-file* while let-bound
> 
> How did you spot that location?

I instrumented the autoload.el code to report it.

In 'autoload-read-section-header' (which was where the "end of file
during parsing" was coming from the call to 'read'), there's code that
takes a buffer-substring, and then edits it in a temporary buffer.  I
made that code print the start and end point of the buffer-substring,
then looked into the old loaddefs.el near the last position it printed
before barfing.

Re: End of file while generating loaddefs.el

[martin rudalics]

 > And anyway, what's the problem with the above?  That's what I have
 > here, after the problem is solved.  I also see that on GNU/Linux,
 > where there was no problem to begin with.

I've put it back.  No problem.

 > Why do you think it's this entry that was the cause of the problem?

I compared the emacs-25 loaddefs with those of master and that was the
only significant difference I found.

 >> I now have
 >>
 >> (autoload 'xref-find-backend "xref" "\
 >> Run...
 >>
 >> \(fn)" nil nil)
 >>
 >> instead and it ran to completion.
 >
 > Great!  Although I don't understand what was the problem with that
 > spot in your case.  Were there any null bytes, anywhere?

I didn't find any.  Do you still have the snippet that caused problems
in your case?  Maybe I can try to patch it somehow into my file and see
whether the problem reappears.

  In 'autoload-read-section-header' (which was where the "end of file
 > during parsing" was coming from the call to 'read'), there's code that
 > takes a buffer-substring, and then edits it in a temporary buffer.  I
 > made that code print the start and end point of the buffer-substring,
 > then looked into the old loaddefs.el near the last position it printed
 > before barfing.

How could null bytes possibly get into that file and why did they cause
an end of file exception during parsing?  And why does no one else have
such problems?

martin

Re: End of file while generating loaddefs.el

[David Kastrup]

martin rudalics <rudalics@gmx.at> writes:

> How could null bytes possibly get into that file and why did they
> cause an end of file exception during parsing?  And why does no one
> else have such problems?

Miscalculation of file offsets because of different EOL convention?
Though NUL bytes sound like a rather low-level mess-up.  You won't get
them just by writing displaced UTF-8.

-- 
David Kastrup

Re: End of file while generating loaddefs.el

[Eli Zaretskii]

> From: David Kastrup <dak@gnu.org>
> Cc: Eli Zaretskii <eliz@gnu.org>,  emacs-devel@gnu.org
> Date: Sat, 21 Nov 2015 12:33:34 +0100
> 
> martin rudalics <rudalics@gmx.at> writes:
> 
> > How could null bytes possibly get into that file and why did they
> > cause an end of file exception during parsing?  And why does no one
> > else have such problems?
> 
> Miscalculation of file offsets because of different EOL convention?

Come on, this is Emacs 25, not 19.30.

> Though NUL bytes sound like a rather low-level mess-up.

That's likely what happened, something with insertion and moving the
gap.  Perhaps even related to the undo changes discussed recently.

Re: End of file while generating loaddefs.el

[Eli Zaretskii]

> Date: Sat, 21 Nov 2015 12:23:52 +0100
> From: martin rudalics <rudalics@gmx.at>
> CC: emacs-devel@gnu.org
> 
> Do you still have the snippet that caused problems in your case?

Yes, I do.

> How could null bytes possibly get into that file

I don't know.  Some bug, obviously, but that's all I can say.  I also
know it happened 7 days ago, because that's the time stamp of the
file.

> and why did they cause an end of file exception during parsing?

That's easy.  This is the guts of autoload-read-section-header:

      (while (looking-at generate-autoload-section-continuation)
	(forward-line 1))
      (setq string (buffer-substring beginning (point)))
      (with-current-buffer (get-buffer-create " *autoload*")
	(erase-buffer)
	(insert string)
	(goto-char (point-min))
	(while (search-forward generate-autoload-section-continuation nil t)
	  (replace-match " "))
	(goto-char (point-min))
	(read (current-buffer))))))

The null bytes cause the first while loop to stop prematurely, and
then buffer-substring copies only part of a sexp into a temporary
buffer.  We then try to read an incomplete sexp from that buffer and
hit the end of the buffer before the sexp ends.

> And why does no one else have such problems?

I don't know, because I don't know what bug caused those null bytes to
appear in the first place.

Re: End of file while generating loaddefs.el

[Juanma Barranquero]

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

On Sat, Nov 21, 2015 at 12:23 PM, martin rudalics <rudalics@gmx.at> wrote:

> And why does no one else have such problems?

I did, about a week ago, but it disappeared right  after the following
update from the repo.

Perhaps it is a gc Heisenbug, as Eli suggested. Compiler options and
whatnot would affect its visibility.

[-- Attachment #2: Type: text/html, Size: 459 bytes --]