From mboxrd@z Thu Jan 1 00:00:00 1970 From: Danny Milosavljevic Subject: Re: wrong type of agument... where ? Date: Sun, 7 Jan 2018 11:46:47 +0100 Message-ID: <20180107114647.13498124@scratchpost.org> References: <20171231132321.0186e7de@scratchpost.org> <20171231153503.3d0f9797@scratchpost.org> <20180101003918.501ab0c3@scratchpost.org> <87zi5qphix.fsf@gmail.com> Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Return-path: Received: from eggs.gnu.org ([2001:4830:134:3::10]:46887) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1eY8Tj-00030R-CU for guix-devel@gnu.org; Sun, 07 Jan 2018 05:47:00 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1eY8Tg-0000zX-4n for guix-devel@gnu.org; Sun, 07 Jan 2018 05:46:59 -0500 Received: from dd26836.kasserver.com ([85.13.145.193]:47972) by eggs.gnu.org with esmtps (TLS1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.71) (envelope-from ) id 1eY8Tf-0000xW-PU for guix-devel@gnu.org; Sun, 07 Jan 2018 05:46:56 -0500 In-Reply-To: <87zi5qphix.fsf@gmail.com> List-Id: "Development of GNU Guix and the GNU System distribution." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: guix-devel-bounces+gcggd-guix-devel=m.gmane.org@gnu.org Sender: "Guix-devel" To: Chris Marusich Cc: guix-devel Hi Chris, On Sat, 06 Jan 2018 17:46:46 -0800 Chris Marusich wrote: > Danny Milosavljevic writes: > > > Try this: > > > > diff --git a/gnu/build/linux-boot.scm b/gnu/build/linux-boot.scm > > index 4dd740174..810a0d63f 100644 > > --- a/gnu/build/linux-boot.scm > > +++ b/gnu/build/linux-boot.scm > > @@ -507,7 +507,14 @@ to it are lost." > > (switch-root "/root") > > (format #t "loading '~a'...\n" to-load) > > > > - (primitive-load to-load) > > + (catch #t > > + (lambda () > > + (primitive-load to-load)) > > + (lambda (key . args) > > + (format (current-error-port) "Error: ~a: ~a\n" key args) > > + (reboot)) > > + (lambda (key . args) > > + (display-backtrace (make-stack #t) (current-error-port)))) > > > > (format (current-error-port) > > "boot program '~a' terminated, rebooting~%" > > > > In some other languages (e.g., Java, Python), we get stack traces by > default when an unhandled exception is thrown. Is this not the case in > Guile? It is the case in Guile, too. But Guile does even more - it automatically drops you into a debugger prompt. Then the tester VM hangs waiting for keyboard input (typing a debugger command) - which we (1) don't want to provide (we want it to fail the unit test automatically and not only after writing "please fail the unit test already" there) and (2) can't provide through the Makefile (right now). Also, we already catch some other exceptions in (guix ui) - and I wanted to pre-empt that. Also, for some reason, directly modifying (guix ui) (see "call-with-error-handling") to handle our new error doesn't work. I tried extending (guix ui) to print a message and that message doesn't appear at runtime either for (gnu build linux-boot) - but visual source code inspection says that (gnu build linux-boot) DOES use (guix ui)'s call-with-error-handling. No idea what's up with that. Maybe some not-rebuilding problem. Every testing round (in this thread, Catonano describes how to test it) takes hours on my computer so if I find a better way it will be by doing a little, from time to time, over weeks. But a quick workaround is the above. Furthermore, the automatic stack trace printer (which is the same as display-backtrace) does some ellipsizing (to keep the total line length under 78 characters or something) and omits valuable information in the stack trace (cuts strings etc). I don't know what's the idea with omitting half the stuff in information meant only for *programmers* in the first place. Therefore, I put a better stack trace printer into bug# 29922 - which is otherwise similar in approach to what I did in this thread here. Also, I think that there's a further bug in Guix in that marionette-operating-system (which is only used for testing) doesn't even exit on guest kernel panic (it just hangs there forever). I've also includes a fix for that in the same patch. I think it's necessary to improve error handling - errors in error handling drive me up a wall. If some contributor already has to battle his own error, we shouldn't prevent him from finding it by our errors :)