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 D70403858C83 for ; Mon, 7 Feb 2022 11:55:48 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org D70403858C83 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-375-VTGT657HMXasZbtJ3f0_dw-1; Mon, 07 Feb 2022 06:55:45 -0500 X-MC-Unique: VTGT657HMXasZbtJ3f0_dw-1 Received: from smtp.corp.redhat.com (int-mx04.intmail.prod.int.phx2.redhat.com [10.5.11.14]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mimecast-mx01.redhat.com (Postfix) with ESMTPS id 19EC78144ED; Mon, 7 Feb 2022 11:55:44 +0000 (UTC) Received: from oldenburg.str.redhat.com (unknown [10.39.193.205]) by smtp.corp.redhat.com (Postfix) with ESMTPS id 3E1F5752A2; Mon, 7 Feb 2022 11:55:43 +0000 (UTC) From: Florian Weimer To: Jacob Kroon Cc: 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> Date: Mon, 07 Feb 2022 12:55:41 +0100 In-Reply-To: <93cd41d6-e333-f31e-96bb-2f34a88f164f@gmail.com> (Jacob Kroon's message of "Mon, 7 Feb 2022 12:46:55 +0100") Message-ID: <875ypqc2ma.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.14 X-Mimecast-Spam-Score: 0 X-Mimecast-Originator: redhat.com Content-Type: text/plain 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 11:55:50 -0000 * Jacob Kroon: > On 2/7/22 09:36, Jacob Kroon wrote: >> Hi Florian, >> >> On 2/4/22 18:15, Florian Weimer wrote: >>> I suspect we are writing beyond the start of the array passed to >>> _dl_sort_maps. >>> >> >> It looks like it is writing passed the beginning of the rpo[] array in >> _dl_sort_maps_dfs(). The output below is right before the crash happens >> (stepping one instruction garbles the backtrace): >> >>> (gdb) bt >>> #0 dfs_traversal (rpo=rpo@entry=0x7fffffffd320, map=0x7ffff7fad590, do_reldeps=do_reldeps@entry=0x0) at dl-sort-maps.c:175 >>> #1 0x00007ffff7fd85d4 in dfs_traversal (do_reldeps=0x0, map=, rpo=0x7fffffffd320) at dl-sort-maps.c:143 >>> #2 dfs_traversal (rpo=rpo@entry=0x7fffffffd320, map=0x7ffff7fadb70, do_reldeps=do_reldeps@entry=0x0) at dl-sort-maps.c:155 >>> #3 0x00007ffff7fd89cd in dfs_traversal (do_reldeps=0x0, map=, rpo=0x7fffffffd320) at dl-sort-maps.c:143 >>> #4 _dl_sort_maps_dfs (skip=, for_fini=, nmaps=15, maps=0x7ffff7953de0) at dl-sort-maps.c:233 >>> #5 _dl_sort_maps (maps=maps@entry=0x7ffff7953de0, nmaps=nmaps@entry=15, skip=, for_fini=for_fini@entry=false) at dl-sort-maps.c:299 >>> #6 0x00007ffff7fcaf0f in _dl_map_object_deps (map=, preloads=, npreloads=, trace_mode=, >>> open_mode=) at dl-deps.c:616 >>> #7 0x00007ffff7fe6970 in dl_main (phdr=, phnum=, user_entry=, auxv=) at rtld.c:1968 >>> #8 0x00007ffff7fe2c7c in _dl_sysdep_start (start_argptr=, dl_main=0x7ffff7fe4bb0 ) at ../elf/dl-sysdep.c:264 >>> #9 0x00007ffff7fe4678 in _dl_start_final (arg=0x7fffffffdec0) at rtld.c:493 >>> #10 _dl_start (arg=0x7fffffffdec0) at rtld.c:587 >>> #11 0x00007ffff7fe36a8 in _start () >>> (gdb) f 0 >>> #0 dfs_traversal (rpo=rpo@entry=0x7fffffffd320, map=0x7ffff7fad590, do_reldeps=do_reldeps@entry=0x0) at dl-sort-maps.c:175 >>> 175 **rpo = map; >>> (gdb) print *rpo >>> $62 = (struct link_map **) 0x7fffffffd238 >>> (gdb) f 4 >>> #4 _dl_sort_maps_dfs (skip=, for_fini=, nmaps=15, maps=0x7ffff7953de0) at dl-sort-maps.c:233 >>> 233 dfs_traversal (&rpo_head, maps[i], do_reldeps_ref); >>> (gdb) print &rpo[-1] >>> $63 = (struct link_map **) 0x7fffffffd238 >> >> I inspected the "maps" vector and it containes *multiple* entries to >> "libjvm.so", is that allowed ? I wonder if "nmaps" is calculated >> correctly, since that determines the array size. Can I verify that somehow ? Curiously I was wondering about duplicates as well as I couldn't sleep. Do you use DT_FILTER or anything unusual? What about LD_PRELOAD? > Actually that is was not correct. "maps[]->l_name" does not contain any > "libjvm.so" at all, but the resulting rpo[] does contain several > "libjvm.so" entries. What I find really confusing is that this is not the result of a dlopen call. I definitely would expect that the maps array contains *all* objects that are being loaded. Clearly this is not the case here. Somehow certain objects are missing, and then they get written into the rpo array. Please try to find libjvm.so among the l_initfini arrays of the objects. It must be present somewhere. I assume it's also on the main list, which starts off at _rtld_global._dl_ns[0]._ns_loaded. Thanks, Florian