From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 26891 invoked by alias); 15 Jan 2015 19:29:12 -0000 Mailing-List: contact gdb-patches-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-patches-owner@sourceware.org Received: (qmail 26874 invoked by uid 89); 15 Jan 2015 19:29:11 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-2.7 required=5.0 tests=AWL,BAYES_00,RCVD_IN_DNSWL_LOW,SPF_PASS,T_RP_MATCHES_RCVD autolearn=ham version=3.3.2 X-HELO: mail-ob0-f179.google.com Received: from mail-ob0-f179.google.com (HELO mail-ob0-f179.google.com) (209.85.214.179) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with (AES128-SHA encrypted) ESMTPS; Thu, 15 Jan 2015 19:29:09 +0000 Received: by mail-ob0-f179.google.com with SMTP id nt9so15248786obb.10 for ; Thu, 15 Jan 2015 11:29:07 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=KwmaT6QUrmwZIxk3A2S0x27jWAiWaN69hEsz9C6twoE=; b=R+CSenl6SWSdqorKKjkCxaUwUvEwtYqMt17fhjp5QRmjnNSkfDN3Ner2pUt3pV7+7P aurY+x4MbNddNRbna3hNhoq2LLlKTlI/yN3zZgfixiLW0HlDjqj3GV2jPBdEMmejxhSH lvpAdLNVtljOP6zTbg2GvXi6bnR2RcVNQaw6BkJeTuPRwEn6N5USQcLVGoou78gvL8F4 /12TmcuENIs9flBBywcvR+FJPU7gNspfAn+Pn4B4cO5GhPSOkR3z32Uf2zrIg5qibTUU iTeRZzLthi99vdsstyeNgSs50CPoRbkHBOxLedLhUC/fP5GM7j/y3GbJmZVG/nKA5VTh I65A== X-Gm-Message-State: ALoCoQnA2DugKxv5G2PRFPCck6tjaTf6o8OrgbKU2quUSvBpj1cikvzdDCxX2JJDwk8KhCPGFiw7 MIME-Version: 1.0 X-Received: by 10.60.178.135 with SMTP id cy7mr6975072oec.66.1421350147417; Thu, 15 Jan 2015 11:29:07 -0800 (PST) Received: by 10.182.222.98 with HTTP; Thu, 15 Jan 2015 11:29:07 -0800 (PST) In-Reply-To: <20150115183316.GA16405@host2.jankratochvil.net> References: <20150115183316.GA16405@host2.jankratochvil.net> Date: Thu, 15 Jan 2015 19:29:00 -0000 Message-ID: Subject: Re: [patch] Sort threads for thread apply all (bt) From: Doug Evans To: Jan Kratochvil Cc: gdb-patches Content-Type: text/plain; charset=UTF-8 X-IsSubscribed: yes X-SW-Source: 2015-01/txt/msg00435.txt.bz2 On Thu, Jan 15, 2015 at 10:33 AM, Jan Kratochvil wrote: > Hi, > > downstream Fedora request: > Please make it easier to find the backtrace of the crashing thread > https://bugzilla.redhat.com/show_bug.cgi?id=1024504 > > Currently after loading a core file GDB prints: > > Core was generated by `./threadcrash1'. > Program terminated with signal SIGSEGV, Segmentation fault. > #0 0x000000000040062f in start (arg=0x0) at threadcrash1.c:8 > 8 *(volatile int *)0=0; > (gdb) _ > > there is nowhere seen which of the threads had crashed. In reality GDB always > numbers that thread as #1 and it is the current thread that time. But after > dumping all the info into a file for later analysis it is no longer obvious. > 'thread apply all bt' even puts the thread #1 to the _end_ of the output!!! > > Should GDB always print after loading a core file what "thread" command would > print? > [Current thread is 1 (Thread 0x7fcbe28fe700 (LWP 15453))] Sounds reasonable to me. Though there is the concern to not even talk about threads if there are "none". So maybe only print that if there is more than one thread? > Or should the "thread" output be printed only in non-interactive mode? > > Or something different? > > Or is the current behavior OK as is and the tools calling GDB in batch mode > should indicate the thread #1 on their own? > > ------------------------------------------------------------------------------ > > I find maybe as good enough and with no risk of UI change flamewar to just > sort the threads by their number. Currently they are printed as they happen > in the internal GDB list which has no advantage. Printing thread #1 as the > first one with assumed 'thread apply all bt' (after the core file is loaded) > should make the complaint resolved I guess. > > No regressions on {x86_64,x86_64-m32,i686}-fedora22pre-linux-gnu. No objection to sorting the list, but if thread #1 is the important one, then a concern could be it'll have scrolled off the screen (such a concern has been voiced in another thread in another context), and if not lost (say it's in an emacs buffer) one would still have to scroll back to see it. So one *could* still want #1 to be last. Do we want an option to choose the sort direction? [I wouldn't make it a global parameter, just an option to thread apply.]