From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from us-smtp-delivery-124.mimecast.com (us-smtp-delivery-124.mimecast.com [170.10.129.124]) by sourceware.org (Postfix) with ESMTPS id 29CAE3858D28 for ; Mon, 7 Feb 2022 16:28:36 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org 29CAE3858D28 Received: from mimecast-mx01.redhat.com (mimecast-mx01.redhat.com [209.132.183.4]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id us-mta-251-2OnDRM3_MMOCl9O6016G9g-1; Mon, 07 Feb 2022 11:28:30 -0500 X-MC-Unique: 2OnDRM3_MMOCl9O6016G9g-1 Received: from smtp.corp.redhat.com (int-mx03.intmail.prod.int.phx2.redhat.com [10.5.11.13]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mimecast-mx01.redhat.com (Postfix) with ESMTPS id 399BE8145E2; Mon, 7 Feb 2022 16:28:29 +0000 (UTC) Received: from oldenburg.str.redhat.com (unknown [10.39.193.205]) by smtp.corp.redhat.com (Postfix) with ESMTPS id BD37B858A0; Mon, 7 Feb 2022 16:28:27 +0000 (UTC) From: Florian Weimer To: Jacob Kroon Cc: cltang@codesourcery.com, adhemerval.zanella@linaro.org, Jacob Kroon via Gdb Subject: Re: Debugging ld.so in gdb References: <29e0ef71-4706-9b0f-2a68-e12c54120d8e@gmail.com> <8735kypwcd.fsf@oldenburg.str.redhat.com> <87y22qognw.fsf@oldenburg.str.redhat.com> <87h79eobq1.fsf@oldenburg.str.redhat.com> <87czk2o967.fsf@oldenburg.str.redhat.com> <06f726f4-855e-239b-fd2c-8d0d57f45131@gmail.com> <878ruqo8o2.fsf@oldenburg.str.redhat.com> <8d9d02de-1a59-1f4d-dbcf-050b65abef29@gmail.com> <93cd41d6-e333-f31e-96bb-2f34a88f164f@gmail.com> <875ypqc2ma.fsf@oldenburg.str.redhat.com> <3e08e7c7-05f5-16f2-50cb-036687386997@gmail.com> <87wni6amk5.fsf@oldenburg.str.redhat.com> <4ea94b1b-71f5-3fbe-e18d-dff61ba3d835@gmail.com> <87zgn293du.fsf@oldenburg.str.redhat.com> Date: Mon, 07 Feb 2022 17:28:25 +0100 In-Reply-To: <87zgn293du.fsf@oldenburg.str.redhat.com> (Florian Weimer's message of "Mon, 07 Feb 2022 15:07:25 +0100") Message-ID: <87y22m7iae.fsf@oldenburg.str.redhat.com> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/27.2 (gnu/linux) MIME-Version: 1.0 X-Scanned-By: MIMEDefang 2.79 on 10.5.11.13 X-Mimecast-Spam-Score: 0 X-Mimecast-Originator: redhat.com Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-Spam-Status: No, score=-6.1 required=5.0 tests=BAYES_00, DKIMWL_WL_HIGH, DKIM_SIGNED, DKIM_VALID, DKIM_VALID_AU, DKIM_VALID_EF, RCVD_IN_DNSWL_LOW, SPF_HELO_NONE, SPF_NONE, TXREP, T_SCC_BODY_TEXT_LINE autolearn=ham autolearn_force=no version=3.4.4 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on server2.sourceware.org X-BeenThere: gdb@sourceware.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Gdb mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 07 Feb 2022 16:28:37 -0000 * Florian Weimer: > * Jacob Kroon: > >> I managed to build glibc master, and yes it also crashes. Reverting the >> suspicious commit: >> >> commit 15a0c5730d1d5aeb95f50c9ec7470640084feae8 >> Author: Chung-Lin Tang >> Date: Thu Oct 21 21:41:22 2021 +0800 >> >> elf: Fix slow DSO sorting behavior in dynamic loader (BZ #17645) >> >> fixes the crash. Adding a couple of more people. > > Sorry, that is completely expected because this is where the faulty code > was added. > > I plan to stare at _dl_map_object_deps a bit, to figure out where the > discrepancy between l_initfini for the main program and the loaded > objects comes from. I can see that we do not add l_fake objects (that failed to load) to the main search list (and nlist is not incremented). But we do not remove them from the individual list of dependencies, leading to this discrepancy. This would be consistent with this bug report: Dynamic loader DFS algorithm segfaults on missing libraries If you run with GLIBC_TUNABLES=3Dglibc.rtld.dynamic_sort=3D0, do you see =E2=80=9Cnot found=E2=80=9D lines in the ldd output? If yes, do these surprising libjvm.so objects have l_fake set in their link map? Thanks, Florian