From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from gnu.wildebeest.org (wildebeest.demon.nl [212.238.236.112]) by sourceware.org (Postfix) with ESMTPS id 2867938515E3 for ; Thu, 25 Mar 2021 10:49:42 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.3.2 sourceware.org 2867938515E3 Authentication-Results: sourceware.org; dmarc=none (p=none dis=none) header.from=klomp.org Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=mark@klomp.org Received: from tarox.wildebeest.org (tarox.wildebeest.org [172.31.17.39]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by gnu.wildebeest.org (Postfix) with ESMTPSA id 19C29302FB96; Thu, 25 Mar 2021 11:49:41 +0100 (CET) Received: by tarox.wildebeest.org (Postfix, from userid 1000) id 021E34091046; Thu, 25 Mar 2021 11:49:40 +0100 (CET) Message-ID: <1032ef77345ce7ac0b4e2d891d661702c4860e77.camel@klomp.org> Subject: Re: Fwd: Buildbot failure in Wildebeest Builder on whole buildset From: Mark Wielaard To: Tom de Vries , dwz@sourceware.org Date: Thu, 25 Mar 2021 11:49:40 +0100 In-Reply-To: <3115ee25dd8a847a1a6de9187ca4418c295c9bbf.camel@klomp.org> References: <20210325084156.1EDD780221F@builder.wildebeest.org> <1f7c4ef1-f454-237e-e7f4-37426c8f44d6@suse.de> <3115ee25dd8a847a1a6de9187ca4418c295c9bbf.camel@klomp.org> Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Mailer: Evolution 3.28.5 (3.28.5-10.el7) Mime-Version: 1.0 X-Spam-Status: No, score=-5.3 required=5.0 tests=BAYES_00, KAM_DMARC_STATUS, 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 10:49:43 -0000 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. > >=20 > > 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? >=20 > 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. >=20 > The problem is simply that: > cp hello 1 > dwz 1 >=20 > Makes dwz produce an exit code of 1 which seems to be interpreted as > child process exited abnormally in a make check run. >=20 > running under valgrind --track-origins=3Dyes gives: >=20 > =3D=3D31313=3D=3D Conditional jump or move depends on uninitialised value= (s) > =3D=3D31313=3D=3D at 0x127974: dwz (dwz.c:15287) > =3D=3D31313=3D=3D by 0x10BB7C: dwz_with_low_mem (dwz.c:16227) > =3D=3D31313=3D=3D by 0x10BB7C: dwz_one_file (dwz.c:16253) > =3D=3D31313=3D=3D by 0x10BB7C: main (dwz.c:16532) > =3D=3D31313=3D=3D Uninitialised value was created by a stack allocation > =3D=3D31313=3D=3D at 0x10B59B: main (dwz.c:16513) >=20 > 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: =3D=3D2502=3D=3D Conditional jump or move depends on uninitialised value(s) =3D=3D2502=3D=3D at 0x13CF4F: dwz (dwz.c:15287) =3D=3D2502=3D=3D by 0x13FE3A: dwz_with_low_mem (dwz.c:16227) =3D=3D2502=3D=3D by 0x13FEAE: dwz_one_file (dwz.c:16253) =3D=3D2502=3D=3D by 0x140B59: main (dwz.c:16532) =3D=3D2502=3D=3D Uninitialised value was created by a stack allocation =3D=3D2502=3D=3D 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 =3D 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 =3D (low_mem_die_limit =3D=3D 0 ? 2 : dwz (file, outfile, res)); And in dwz the first thing we do is: if (res->res =3D=3D -1) return 1; But res->res was never given a value and so could be anything. Cheers, Mark