From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from smtp.CeBiTec.Uni-Bielefeld.DE (smtp.CeBiTec.Uni-Bielefeld.DE [129.70.160.84]) by sourceware.org (Postfix) with ESMTPS id 85BB0388B01F for ; Tue, 16 Jun 2020 14:21:47 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.3.2 sourceware.org 85BB0388B01F Authentication-Results: sourceware.org; dmarc=none (p=none dis=none) header.from=CeBiTec.Uni-Bielefeld.DE Authentication-Results: sourceware.org; spf=none smtp.mailfrom=ro@cebitec.uni-bielefeld.de Received: from localhost (localhost [127.0.0.1]) by smtp.CeBiTec.Uni-Bielefeld.DE (Postfix) with ESMTP id AAD82A7878; Tue, 16 Jun 2020 16:21:46 +0200 (CEST) X-Virus-Scanned: amavisd-new at CeBiTec.Uni-Bielefeld.DE Received: from smtp.CeBiTec.Uni-Bielefeld.DE ([127.0.0.1]) by localhost (smtp.cebitec.uni-bielefeld.de [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cczLAcLoGhBR; Tue, 16 Jun 2020 16:21:46 +0200 (CEST) Received: from manam.CeBiTec.Uni-Bielefeld.DE (p4fddbb33.dip0.t-ipconnect.de [79.221.187.51]) by smtp.CeBiTec.Uni-Bielefeld.DE (Postfix) with ESMTPSA id 33A6FA7D65; Tue, 16 Jun 2020 16:21:46 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=CeBiTec.Uni-Bielefeld.DE; s=20200306; t=1592317306; bh=qQ+8CwDUsjas7SFrk4n2kCZ3FSegHBriITO6c2/uDV0=; h=From:To:Cc:Subject:Date:From; b=kKUyo48cK0ghA04guPqZPJumiB0j3qhl8POwVkedpEKdE07kbhI0GuMya5uAVUKII lgRNuzb83TYGSkSO2zWUCKiu253vZvke2YH/7tJJr7mI1AHLEQtk93e1LWIxzTbZHV QVT8R9nwL1o1bIR1WTGc49m/3iuRDsxbt4NCCy7nIFZihQNFFxkxnM+w+0yaZ2qDa0 qd+7BKUletvSq4F+JQyom90ofvMTlXnb+RmCWlrGQXDQY6bsQqHHZPRAdNY3p5Y621 Jxclmr3ji8iy6wPknqWQaAALaOZlvpzywub6kgMOojremXN5qOmsSe7fyhJbLePTKT 5RxSCqFNFIrUg== From: Rainer Orth To: gdb-patches@sourceware.org Cc: Pedro Alves Subject: Unbreaking gdb on Solaris post-multitarget [PR 25939] Date: Tue, 16 Jun 2020 16:21:45 +0200 Message-ID: User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/26.3 (usg-unix-v) MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="=-=-=" X-Spam-Status: No, score=-3796.1 required=5.0 tests=BAYES_00, DKIM_SIGNED, DKIM_VALID, DKIM_VALID_AU, GIT_PATCH_0, SPF_HELO_NONE, SPF_NONE, 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: 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, 16 Jun 2020 14:21:49 -0000 --=-=-= Content-Type: text/plain Some time ago, when testing gdb master on Solaris again after several months, I discovered that gdb couldn't execute even a trivial program anymore. This had gone unnoticed by the Solaris buildbots since the code continued to compile just fine. Those bots are build-only since many tests (especially thread tests) are either flaky or time out. A reghunt identified the multi-target merge as the culprit. Here's what I see: $ ./gdb -D ./data-directory ./hello GNU gdb (GDB) 10.0.50.20200106-git [...] Reading symbols from ./hello... (gdb) run Starting program: /vol/obj/gnu/gdb/gdb/reghunt/no-resync/122448/gdb/hello /vol/src/gnu/gdb/hg/master/reghunt/gdb/thread.c:336: internal-error: thread_info::thread_info(inferior*, ptid_t): Assertion `inf_ != NULL' failed. Here's the start of the corresponding stack trace: #0 internal_error ( file=file@entry=0x966150 "/vol/src/gnu/gdb/hg/master/reghunt/gdb/thread.c", line=line@entry=336, fmt=0x9ddb94 "%s: Assertion `%s' failed.") at /vol/src/gnu/gdb/hg/master/reghunt/gdb/gdbsupport/errors.c:51 #1 0x0000000000ef81f4 in thread_info::thread_info (this=0x1212020, inf_=, ptid_=...) at /vol/src/gnu/gdb/hg/master/reghunt/gdb/thread.c:344 #2 0x0000000000ef82cd in new_thread (inf=inf@entry=0x0, ptid=...) at /vol/src/gnu/gdb/hg/master/reghunt/gdb/thread.c:239 #3 0x0000000000efac3c in add_thread_silent ( targ=targ@entry=0x11b0940 , ptid=...) at /vol/src/gnu/gdb/hg/master/reghunt/gdb/thread.c:304 #4 0x0000000000d90692 in procfs_target::create_inferior ( this=0x11b0940 , exec_file=0x13dbef0 "/vol/obj/gnu/gdb/gdb/reghunt/no-resync/122448/gdb/hello", allargs="", env=0x13c48f0, from_tty=) at /vol/src/gnu/gdb/hg/master/reghunt/gdb/gdbsupport/ptid.h:47 #5 0x0000000000c84e64 in run_command_1 (args=, from_tty=1, run_how=run_how@entry=RUN_NORMAL) at /vol/gcc-9/include/c++/9.1.0/bits/basic_string.h:263 #6 0x0000000000c85007 in run_command (args=, from_tty=) at /vol/src/gnu/gdb/hg/master/reghunt/gdb/infcmd.c:687 Looking closer, I found that in add_thread_silent as called from procfs.c (procfs_target::create_inferior) find_inferior_ptid returns NULL. The all_inferiors (targ) iterator comes up empty. Going from there, I see that in add_thread_silent m_target_stack = {m_top = file_stratum, m_stack = {0x20190e0 , 0x200b8c0 , 0x0, 0x0, 0x0, 0x0, 0x0}}} i.e. the_procfs_target is missing compared to the_amd64_linux_nat_target on Linux/x86_64. I've managed to get a bit further with the following patch which is intended to push the procfs target first: --=-=-= Content-Type: text/x-patch Content-Disposition: inline; filename=reghunt.patch diff --git a/gdb/procfs.c b/gdb/procfs.c --- a/gdb/procfs.c +++ b/gdb/procfs.c @@ -3086,6 +3090,9 @@ procfs_target::create_inferior (const ch shell_file = tryname; } + if (!target_is_pushed (this)) + push_target (this); + pid = fork_inferior (exec_file, allargs, env, procfs_set_exec_trap, NULL, NULL, shell_file, NULL); --=-=-= Content-Type: text/plain However, while I now get over the initial assertion failure, I run instead into procfs: couldn't find pid 0 in procinfo list. procfs: init_inferior, open_proc_files line 2878, /proc/6031: No such file or directory. When I break in procfs.c (procfs_init_inferior), I can see that create_procinfo succeeds. However, looking at the process tree at this point, I see that the debuggee is still marked as defunct 18377 /vol/gcc/bin/gdb -i=mi /vol/gnu/obj/gdb/gdb/reghunt/no-r 18379 /vol/gnu/obj/gdb/gdb/reghunt/no-resync/122457/gdb/gdb 18382 so open_procinfo_files fails because /proc/ only contains psinfo and usage, but no ctl file yet. I tried to do the same with a version of gdb from immediately before the multi-target merge: while that can run a test program interactively just fine, running that gdb under gdb itself most often leads to the same error. This very much seems like a race condition to me, but at the moment I'm pretty much at a loss how to investigate this further. So I'd very much appreciate any suggestions and help to make gdb work again on Solaris. Thanks. Rainer -- ----------------------------------------------------------------------------- Rainer Orth, Center for Biotechnology, Bielefeld University --=-=-=--