Volunteers to implement test for stuff called at startup?

Volunteers to implement test for stuff called at startup?

[Eli Zaretskii]

From time to time, as part of development, we install changes that
break some rare platforms or configurations.  One reason for that is
inadvertent calls during startup sequence to primitives that are
either not yet set up (because Emacs is in the middle of its startup),
or are simply not available in those rare configurations.

For example, a recent change caused process-list to be called very
early during startup.  The code that was installed was not intended to
run during startup, I think, so this was an inadvertent side effect.
If the fact that process-list is called when Emacs starts was evident
at the time, I'm sure several brows would have been raised, and the
author would have been asked to explain why that is needed, with the
result that this code could have been scrutinized in time for us to
either change it not to run during startup, or add some conditions
that would have avoided the trouble, or whatever.

So with this in mind, one idea that could help us detect similar
situations in the future would be to have a test in the test suite
that would record every primitive called during startup, compare it
against some expected list, and flag any changes (at least additions,
not sure about deletions).  Then both people who run the test suite
regularly and bots like Hydra could flag any changes and let us handle
these potential problems when they are young.

Does that make sense?  If so, would someone like to volunteer for the
job?

TIA

Re: Volunteers to implement test for stuff called at startup?

[Richard Stallman]

[[[ To any NSA and FBI agents reading my email: please consider    ]]]
[[[ whether defending the US Constitution against all enemies,     ]]]
[[[ foreign or domestic, requires you to follow Snowden's example. ]]]

  > For example, a recent change caused process-list to be called very
  > early during startup.  The code that was installed was not intended to
  > run during startup, I think, so this was an inadvertent side effect.

A simple way to detect this would be to have a global flag
process_list_ok_to_call, which starts out 0 and gets set to 1
at the stage where calling it becomes ok.  If you call process-list
and process_list_ok_to_call is 0, it would signal an error.

This is more effective as a test mechanism than writing tests, and
simpler than the solution of making a list of all primitives called
and checking that.

Perhaps a few such variables would be enough to identify
the various stages of startup, so that various primitives can
test one of these.


Another approach for this case is to initialize Vprocess_list earlier.
Or make process-list return nil when Vprocess_list is 0.  Then there
would be no problem calling process-list too early.

-- 
Dr Richard Stallman
President, Free Software Foundation (gnu.org, fsf.org)
Internet Hall-of-Famer (internethalloffame.org)
Skype: No way! See stallman.org/skype.html.

Re: Volunteers to implement test for stuff called at startup?

[Kaushal Modi]

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

Hi Eli,

Starting today morning (probably my first build after the update in
src/process.c), I am unable to update M-x list-packages. I keep on getting
the below error.

=====

Importing package-keyring.gpg...done
error in process filter: End of file during parsing

=====

The below is not helping me here as this error originates in C.

(setq debug-on-message "error in process filter")

I do not know for sure if the update in process.c or some package in GNU
elpa/melpa would cause this. Can you please provide me pointers to help
provide good debug info? Also can that error be improved to give more info
as to which file caused the "End of file during parsing" error?

Thanks.


-- 

-- 
Kaushal Modi

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

Re: Volunteers to implement test for stuff called at startup?

[Robert Pluim]

Kaushal Modi <kaushal.modi@gmail.com> writes:

> Hi Eli,
>
> Starting today morning (probably my first build after the update in
> src/process.c), I am unable to update M-x list-packages. I keep on getting
> the below error.
>
> =====
>
> Importing package-keyring.gpg...done
> error in process filter: End of file during parsing

(I'm seeing this as well, but it had been working fine for quite some
time)

It looks like melpa is having issues:

https://github.com/melpa/melpa/issues/3833

Re: Volunteers to implement test for stuff called at startup?

[Kaushal Modi]

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

>
> (I'm seeing this as well, but it had been working fine for quite some
> time)
>
> It looks like melpa is having issues:
>
> https://github.com/melpa/melpa/issues/3833


Thanks!

I already opened an issue for this (
http://debbugs.gnu.org/cgi/bugreport.cgi?bug=23424 ). Hopefully we can put
more info in that error message and make the source of that easier to
trace...?
-- 

-- 
Kaushal Modi

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

Re: Volunteers to implement test for stuff called at startup?

[Eli Zaretskii]

> From: Kaushal Modi <kaushal.modi@gmail.com>
> Date: Mon, 02 May 2016 15:08:18 +0000
> Cc: emacs-devel@gnu.org
> 
> Starting today morning (probably my first build after the update in src/process.c), I am unable to update M-x
> list-packages. I keep on getting the below error.
> 
> =====
> 
> Importing package-keyring.gpg...done
> error in process filter: End of file during parsing
> 
> =====
> 
> The below is not helping me here as this error originates in C.
> 
> (setq debug-on-message "error in process filter")
> 
> I do not know for sure if the update in process.c or some package in GNU elpa/melpa would cause this.

The changes in process.c are unlikely to be the culprit, as they
didn't change anything on your platform, just moved existing code
around.

But if you provide an exact recipe, I can try this on my machine and
see what I come up with.

> Can you please provide me pointers to help provide good debug info?

The most efficient method is to debug this in C.  By limiting yourself
to Lisp, you are unnecessarily making your job much harder and wasting
your time on something that is very easy to do using GDB.  Time to
cross that bridge, perhaps?  Here are the instructions in case you
decide to do it:

Just set a breakpoint in Fsignal, and when it breaks, type "bt" to
display the backtrace.  Start GDB from the src directory, so it will
display both C and Lisp backtrace when you type that command.

Additional info is in etc/DEBUG.

> Also can that error be improved to give more info as to which file
> caused the "End of file during parsing" error?

What improvement did you have in mind?  The error message generally
means the stream from which the Emacs reader was reading hit EOF.

In any case, I suggest to postpone this latter issue until you find
out the cause of the problem, because otherwise we are discussing a
situation we don't sufficiently understand.

Re: Volunteers to implement test for stuff called at startup?

[Kaushal Modi]

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

>
> The most efficient method is to debug this in C.  By limiting yourself
> to Lisp, you are unnecessarily making your job much harder and wasting
> your time on something that is very easy to do using GDB.  Time to
> cross that bridge, perhaps?  Here are the instructions in case you
> decide to do it:
>
> Just set a breakpoint in Fsignal, and when it breaks, type "bt" to
> display the backtrace.  Start GDB from the src directory, so it will
> display both C and Lisp backtrace when you type that command.
>
> Additional info is in etc/DEBUG.
>

Thanks! Looks like I will need to cross that bridge eventually. For this
problem though, the source is identified, but I wished that error gave a
direct pointer (see below).


> What improvement did you have in mind?  The error message generally
> means the stream from which the Emacs reader was reading hit EOF.
>

As someone reported in a Melpa github issue, the problem is that the Melpa
archive-contents ( http://melpa.org/packages/archive-contents ) is
corrupted (as of writing this).

If the above problem is fixed at the time of viewing this email, this is
what archive-contents ended with:

=====
https://github.com/cosmicexplorer/cloc-emacs") (:keywords "cloc" "count"
"source" "code" "lines"))]) (clmemo . [(20160326 923) nil "Change Log MEMO"
tar ((:url . "https://github.com/ataka/clmemo") (:keywords
"convenience"))]) (cljsbuild-mode . [(20160402 1000) nil "A minor mode for
the ClojureScript 'lein cljsbuild' command" single ((:url . "
http://github.com/kototama/cljsbuild-mode") (:keywords "clojure"
"clojurescript" "leiningen" "compilation"))]) (cljr-helm . [(20150425 1307)
((clj-refactor (0 13 0)) (helm (1 5 6))) "Wraps clojure refactor commands
with helm" single ((:url . "https://github.com/philjackson/cljr-he
=====

So the improvement request is if it's possible for emacs to print the path
to the offending file so that, in this case, the error would directly tell
that EOF error was found in archive-contents downloaded from Melpa.
-- 

-- 
Kaushal Modi

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

Re: Volunteers to implement test for stuff called at startup?

[Eli Zaretskii]

> From: Kaushal Modi <kaushal.modi@gmail.com>
> Date: Mon, 02 May 2016 15:44:24 +0000
> Cc: emacs-devel@gnu.org
> 
>  What improvement did you have in mind? The error message generally
>  means the stream from which the Emacs reader was reading hit EOF.
> 
> As someone reported in a Melpa github issue, the problem is that the Melpa archive-contents (
> http://melpa.org/packages/archive-contents ) is corrupted (as of writing this).
> 
> If the above problem is fixed at the time of viewing this email, this is what archive-contents ended with: 
> 
> =====
> https://github.com/cosmicexplorer/cloc-emacs") (:keywords "cloc" "count" "source" "code" "lines"))]) (clmemo
> . [(20160326 923) nil "Change Log MEMO" tar ((:url . "https://github.com/ataka/clmemo") (:keywords
> "convenience"))]) (cljsbuild-mode . [(20160402 1000) nil "A minor mode for the ClojureScript 'lein cljsbuild'
> command" single ((:url . "http://github.com/kototama/cljsbuild-mode") (:keywords "clojure" "clojurescript"
> "leiningen" "compilation"))]) (cljr-helm . [(20150425 1307) ((clj-refactor (0 13 0)) (helm (1 5 6))) "Wraps clojure
> refactor commands with helm" single ((:url . "https://github.com/philjackson/cljr-he
> =====
> 
> So the improvement request is if it's possible for emacs to print the path to the offending file so that, in this
> case, the error would directly tell that EOF error was found in archive-contents downloaded from Melpa.

As you see from the detailed backtrace I posted for your bug report,
the problem happens when Emacs tries to read from an empty string, so
there's no file to report.

Re: Volunteers to implement test for stuff called at startup?

[Kaushal Modi]

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

>
> As you see from the detailed backtrace I posted for your bug report,
> the problem happens when Emacs tries to read from an empty string, so
> there's no file to report.
>

Thanks Eli, I have continued the discussion in that bug thread (
http://debbugs.gnu.org/cgi/bugreport.cgi?bug=23424 ).
-- 

-- 
Kaushal Modi

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

Re: Volunteers to implement test for stuff called at startup?

[John Wiegley]

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

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

> So with this in mind, one idea that could help us detect similar situations
> in the future would be to have a test in the test suite that would record
> every primitive called during startup, compare it against some expected
> list, and flag any changes (at least additions, not sure about deletions).
> Then both people who run the test suite regularly and bots like Hydra could
> flag any changes and let us handle these potential problems when they are
> young.

> Does that make sense? If so, would someone like to volunteer for the job?

I like this idea. The approach of gathering a "primitives" list, and comparing
it after each test run, doesn't require as much legwork as Richard's
suggestion -- where we'd need to know ahead of time every such flag of
interest.

I'll second the call: any volunteers?

-- 
John Wiegley                  GPG fingerprint = 4710 CF98 AF9B 327B B80F
http://newartisans.com                          60E1 46C4 BD1A 7AC1 4BA2

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 629 bytes --]