From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from smtp.polymtl.ca (smtp.polymtl.ca [132.207.4.11]) by sourceware.org (Postfix) with ESMTPS id 45DDB384F039 for ; Tue, 13 Jul 2021 04:49:21 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org 45DDB384F039 Received: from simark.ca (simark.ca [158.69.221.121]) (authenticated bits=0) by smtp.polymtl.ca (8.14.7/8.14.7) with ESMTP id 16D4nBjT012257 (version=TLSv1/SSLv3 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Tue, 13 Jul 2021 00:49:16 -0400 DKIM-Filter: OpenDKIM Filter v2.11.0 smtp.polymtl.ca 16D4nBjT012257 Received: from [10.0.0.11] (192-222-157-6.qc.cable.ebox.net [192.222.157.6]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by simark.ca (Postfix) with ESMTPSA id A09501E01B; Tue, 13 Jul 2021 00:49:11 -0400 (EDT) Subject: Re: [PATCH][gdb/testsuite] Fix check-libthread-db.exp FAILs with glibc 2.33 To: Tom de Vries , gdb-patches@sourceware.org References: <20210707140950.GA2241@delia> From: Simon Marchi Message-ID: <2421785c-a5b9-64b7-371c-0abf35a4cb63@polymtl.ca> Date: Tue, 13 Jul 2021 00:49:11 -0400 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:78.0) Gecko/20100101 Thunderbird/78.11.0 MIME-Version: 1.0 In-Reply-To: <20210707140950.GA2241@delia> Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit X-Poly-FromMTA: (simark.ca [158.69.221.121]) at Tue, 13 Jul 2021 04:49:11 +0000 X-Spam-Status: No, score=-3.9 required=5.0 tests=BAYES_00, DKIM_SIGNED, DKIM_VALID, DKIM_VALID_AU, DKIM_VALID_EF, KAM_NUMSUBJECT, NICE_REPLY_A, RCVD_IN_MSPIKE_H3, RCVD_IN_MSPIKE_WL, SPF_HELO_PASS, SPF_PASS, TXREP 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-patches@sourceware.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Gdb-patches mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 13 Jul 2021 04:49:22 -0000 On 2021-07-07 10:09 a.m., Tom de Vries wrote: > Hi, > > When running test-case gdb.threads/check-libthread-db.exp on openSUSE > Tumbleweed with glibc 2.33, I get: > ... > (gdb) maint check libthread-db^M > Running libthread_db integrity checks:^M > Got thread 0x7ffff7c79b80 => 9354 => 0x7ffff7c79b80; errno = 0 ... OK^M > libthread_db integrity checks passed.^M > (gdb) FAIL: gdb.threads/check-libthread-db.exp: user-initiated check: libpthread.so not initialized (pattern 2) > ... > > The test-case expects instead: > ... > Got thread 0x0 => 9354 => 0x0 ... OK^M > ... > which is what I get on openSUSE Leap 15.2 with glibc 2.26, and what is > described in the test-case like this: > ... > # libthread_db should fake a single thread with th_unique == NULL. > ... > > Using a breakpoint on check_thread_db_callback we can compare the two > scenarios, and find that in the latter case we hit this code in glibc function > iterate_thread_list in nptl_db/td_ta_thr_iter.c: > ... > if (next == 0 && fake_empty) > { > /* __pthread_initialize_minimal has not run. There is just the main > thread to return. We cannot rely on its thread register. They > sometimes contain garbage that would confuse us, left by the > kernel at exec. So if it looks like initialization is incomplete, > we only fake a special descriptor for the initial thread. */ > td_thrhandle_t th = { ta, 0 }; > return callback (&th, cbdata_p) != 0 ? TD_DBERR : TD_OK; > } > ... > while in the former case we don't because this preceding statement doesn't > result in next == 0: > ... > err = DB_GET_FIELD (next, ta, head, list_t, next, 0); > ... > > Note that the comment mentions __pthread_initialize_minimal, but in both cases > it has already run before we hit the callback, so it's possible the comment is > no longer accurate. > > Anyway, the results do not look wrong, so fix this by updating the regexp > patterns to agree with what libthread-db is telling us. > > Tested on x86_64-linux, both with glibc 2.33 and 2.26. > > Any comments? I got a bit lost in the glibc code, but I am wondering if this change in behavior might have been caused by this glibc change: https://gitlab.com/gnutools/glibc/-/commit/1daccf403b1bd86370eb94edca794dc106d02039 Before this, the stack_user list was global variables. This is one of the two lists that get walked to enumerate the threads. Since it isn't initialized statically, it got placed in .bss and is zeroed-out by default, hence why thread-db expected to read next == 0, I guess. Or, it may be that the moment that this nptl minimal initialization is done has changed, at least relative to where we do our checks. It looks like __pthread_initialize_minimal_internal is called as a constructor. Has it always been this way? By the time we stop on the solib load event, have the constructors of the lib ran? In any case, I agree that this looks benign, the regexp checks we have exactly one thread. But I would still be curious to know the real reason for the change in behavior. Simon