From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Eli Zaretskii Newsgroups: gmane.emacs.devel Subject: Re: Volunteers to implement test for stuff called at startup? Date: Mon, 02 May 2016 18:32:53 +0300 Message-ID: <8360uwmq56.fsf@gnu.org> References: <83y47tn5tv.fsf@gnu.org> Reply-To: Eli Zaretskii NNTP-Posting-Host: plane.gmane.org X-Trace: ger.gmane.org 1462203229 23327 80.91.229.3 (2 May 2016 15:33:49 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Mon, 2 May 2016 15:33:49 +0000 (UTC) Cc: rms@gnu.org, emacs-devel@gnu.org To: Kaushal Modi Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Mon May 02 17:33:39 2016 Return-path: Envelope-to: ged-emacs-devel@m.gmane.org Original-Received: from lists.gnu.org ([208.118.235.17]) by plane.gmane.org with esmtp (Exim 4.69) (envelope-from ) id 1axFqr-0003b4-Vi for ged-emacs-devel@m.gmane.org; Mon, 02 May 2016 17:33:38 +0200 Original-Received: from localhost ([::1]:37241 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1axFqo-0003Xb-2s for ged-emacs-devel@m.gmane.org; Mon, 02 May 2016 11:33:34 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:51552) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1axFqW-0003ML-5R for emacs-devel@gnu.org; Mon, 02 May 2016 11:33:22 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1axFqK-0000S1-Hf for emacs-devel@gnu.org; Mon, 02 May 2016 11:33:10 -0400 Original-Received: from fencepost.gnu.org ([2001:4830:134:3::e]:60016) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1axFqK-0000RM-Et; Mon, 02 May 2016 11:33:04 -0400 Original-Received: from 84.94.185.246.cable.012.net.il ([84.94.185.246]:3359 helo=home-c4e4a596f7) by fencepost.gnu.org with esmtpsa (TLS1.2:RSA_AES_128_CBC_SHA1:128) (Exim 4.82) (envelope-from ) id 1axFq6-0001s3-Oh; Mon, 02 May 2016 11:32:51 -0400 In-reply-to: (message from Kaushal Modi on Mon, 02 May 2016 15:08:18 +0000) X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic] X-Received-From: 2001:4830:134:3::e X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.21 Precedence: list List-Id: "Emacs development discussions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Original-Sender: "Emacs-devel" Xref: news.gmane.org gmane.emacs.devel:203519 Archived-At: > From: Kaushal Modi > 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.