From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mx2.suse.de (mx2.suse.de [195.135.220.15]) by sourceware.org (Postfix) with ESMTPS id 97A1C386102B for ; Thu, 25 Mar 2021 14:01:58 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.3.2 sourceware.org 97A1C386102B Authentication-Results: sourceware.org; dmarc=none (p=none dis=none) header.from=suse.de Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=tdevries@suse.de X-Virus-Scanned: by amavisd-new at test-mx.suse.de Received: from relay2.suse.de (unknown [195.135.221.27]) by mx2.suse.de (Postfix) with ESMTP id A569FADE3; Thu, 25 Mar 2021 14:01:57 +0000 (UTC) Subject: Re: Fwd: Buildbot failure in Wildebeest Builder on whole buildset To: Mark Wielaard , dwz@sourceware.org References: <20210325084156.1EDD780221F@builder.wildebeest.org> <1f7c4ef1-f454-237e-e7f4-37426c8f44d6@suse.de> <3115ee25dd8a847a1a6de9187ca4418c295c9bbf.camel@klomp.org> <1032ef77345ce7ac0b4e2d891d661702c4860e77.camel@klomp.org> From: Tom de Vries Message-ID: <2d760053-00cb-5de7-3e16-11d9959328aa@suse.de> Date: Thu, 25 Mar 2021 15:01:57 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:78.0) Gecko/20100101 Thunderbird/78.8.0 MIME-Version: 1.0 In-Reply-To: <1032ef77345ce7ac0b4e2d891d661702c4860e77.camel@klomp.org> Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit X-Spam-Status: No, score=-6.2 required=5.0 tests=BAYES_00, KAM_DMARC_STATUS, NICE_REPLY_A, RCVD_IN_MSPIKE_H3, RCVD_IN_MSPIKE_WL, SPF_HELO_NONE, SPF_PASS, TXREP autolearn=ham autolearn_force=no version=3.4.2 X-Spam-Checker-Version: SpamAssassin 3.4.2 (2018-09-13) on server2.sourceware.org X-BeenThere: dwz@sourceware.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Dwz mailing list List-Unsubscribe: , List-Archive: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 25 Mar 2021 14:01:59 -0000 On 3/25/21 11:49 AM, Mark Wielaard wrote: > Hi Tom, > > On Thu, 2021-03-25 at 11:41 +0100, Mark Wielaard wrote: >> On Thu, 2021-03-25 at 09:50 +0100, Tom de Vries wrote: >>> I've just committed patch "Move hardlink handling out of dwz >>> function" >>> and there's this buildbot failure. >>> >>> Is there something easy that you can do to find out if this is a >>> fluke >>> or not, f.i. retry the build for that bot? >> >> I logged into the buildbot worker and did a dwz build myself. >> make check does produce 32 unexpected failures. >> Removing the last commit makes everything pass. >> Adding the commit again produces the failures again. >> It isn't a fluke. >> >> The problem is simply that: >> cp hello 1 >> dwz 1 >> >> Makes dwz produce an exit code of 1 which seems to be interpreted as >> child process exited abnormally in a make check run. >> >> running under valgrind --track-origins=yes gives: >> >> ==31313== Conditional jump or move depends on uninitialised value(s) >> ==31313== at 0x127974: dwz (dwz.c:15287) >> ==31313== by 0x10BB7C: dwz_with_low_mem (dwz.c:16227) >> ==31313== by 0x10BB7C: dwz_one_file (dwz.c:16253) >> ==31313== by 0x10BB7C: main (dwz.c:16532) >> ==31313== Uninitialised value was created by a stack allocation >> ==31313== at 0x10B59B: main (dwz.c:16513) >> >> I haven't tracked down what res->res precisely depends on that >> doesn't >> have a defined value. > > Note that dwz_one_file was inlined into main, causing valgrind to > pinpoint the wrong frame. Without inlining we get: > > ==2502== Conditional jump or move depends on uninitialised value(s) > ==2502== at 0x13CF4F: dwz (dwz.c:15287) > ==2502== by 0x13FE3A: dwz_with_low_mem (dwz.c:16227) > ==2502== by 0x13FEAE: dwz_one_file (dwz.c:16253) > ==2502== by 0x140B59: main (dwz.c:16532) > ==2502== Uninitialised value was created by a stack allocation > ==2502== at 0x13FE7F: dwz_one_file (dwz.c:16245) > > And indeed we see: > > static int > dwz_one_file (const char *file, const char *outfile) > { > struct file_result res; > > if (stats_p) > init_stats (file); > > res.die_count = 0; > > return dwz_with_low_mem (file, outfile, &res, NULL); > } > > Defines and passes down res, but only initializes the die_count field. > > Then in dwz_with_low_mem we simply pass that res to dwz: > > ret = (low_mem_die_limit == 0 > ? 2 > : dwz (file, outfile, res)); > > And in dwz the first thing we do is: > > if (res->res == -1) > return 1; > > But res->res was never given a value and so could be anything. > Hi Mark, thanks for helping out with this. I've fixed this now, and verified that the buildbot is back to all-green. After seeing your analysis, I realized I had tried -fsanitize=address but not valgrind, and indeed using valgrind I managed to reproduce the problem myself. I've submitted a patch proposing a check-valgrind target in the Makefile, to remind me to try this next time. Thanks, - Tom