From mboxrd@z Thu Jan 1 00:00:00 1970 From: Roel Janssen Subject: bug#29676: Guix test failure on tests/store. Date: Thu, 21 Dec 2017 20:53:47 +0100 Message-ID: <87inczhn78.fsf@gnu.org> References: <87tvwwcfhn.fsf@gnu.org> <87shcgorq5.fsf@gnu.org> <87shcfdh5w.fsf@gnu.org> <871sjzitmm.fsf@gnu.org> <87ind1y262.fsf@gnu.org> <87vah0ruyr.fsf@gnu.org> <874lok5dmm.fsf@gnu.org> Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit Return-path: Received: from eggs.gnu.org ([2001:4830:134:3::10]:47400) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1eS6vp-0007Nf-Vd for bug-guix@gnu.org; Thu, 21 Dec 2017 14:55:07 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1eS6vm-0005Gb-JI for bug-guix@gnu.org; Thu, 21 Dec 2017 14:55:06 -0500 Received: from debbugs.gnu.org ([208.118.235.43]:37817) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.71) (envelope-from ) id 1eS6vm-0005GU-FM for bug-guix@gnu.org; Thu, 21 Dec 2017 14:55:02 -0500 Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1eS6vm-0003jq-4Z for bug-guix@gnu.org; Thu, 21 Dec 2017 14:55:02 -0500 Sender: "Debbugs-submit" Resent-Message-ID: In-reply-to: <874lok5dmm.fsf@gnu.org> List-Id: Bug reports for GNU Guix List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: bug-guix-bounces+gcggb-bug-guix=m.gmane.org@gnu.org Sender: "bug-Guix" To: Ludovic =?UTF-8?Q?Court=C3=A8s?= Cc: 29676@debbugs.gnu.org Ludovic Courtès writes: > Roel Janssen skribis: > >> Ludovic Courtès writes: >> >>> Hi Roel, >>> >>> ludo@gnu.org (Ludovic Courtès) skribis: >>> >>>> Roel Janssen skribis: >>> >>> [...] >>> >>>>>>> actual-error: >>>>>>> + (srfi-34 >>>>>>> + #) >>>>>>> result: FAIL >>>>>> >>>>>> The “dtmp” bit (instead of “/tmp”) looks fishy and would suggest a >>>>>> memory corruption, presumably in the daemon. >>>>> >>>>> The daemon used in the test, or the daemon used to do the package build? >>>> >>>> The daemon under test (within the build environment). >>>> >>>>>> I suppose the failure random, isn’t it? >>>>> >>>>> I ran it again, and I've got the same error: >>>>> >>>>> actual-error: >>>>> + (srfi-34 >>>>> + #) >>>>> >>>>> So that's either a very funny coincidence, or it's a structural problem. >>>> >>>> It’s better if it’s not random. :-) >>>> >>>>> Do you have any suggestions for how I can debug this problem? >>>> >>>> Assuming the failure also happens when you run “make check” outside the >>>> build container (in the failed build tree), can you add ‘valgrind’ in >>>> ‘test-env’? Specifically, in ‘test-env’, look for the line that invokes >>>> ‘./pre-inst-env guix-daemon’ and change it to ‘./pre-inst-env valgrind >>>> guix-daemon’. >>> >>> Did you manage to gather more info? >> >> No. When I run "make check -k" many tests fail. > > In a fresh checkout? If many tests fail, then there’s probably > something wrong with the environment, such as guix-daemon failing to > start or something. Could you check the logs? > > Thanks, > Ludo’. Indeed. I found out that guix-daemon couldn't start because I didn't set --localstatedir properly. I "make check" again and that yields the same issue with tests/store.scm. However, upon changing test-env to include valgrind, more tests fail again because of a problem accessing the daemon-socket. So I manually started the guix-daemon with --disable-chroot and prepended valgrind --leak-check=full to it. Then I ran: $ guile -s tests/store.scm Which yielding many more failures. Then: $ make check Which also yielded more test failures. But at least I have a valgrind log now, which I uploaded here: https://www.roelj.com/guix-daemon-valgrind.log.gz I don't think the memory problem is in the log, but at least it shows that we should have a look at the memory allocation of guix-daemon. Sometimes it seems to leak memory. Kind regards, Roel Janssen