From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 45048 invoked by alias); 6 Feb 2020 22:06:18 -0000 Mailing-List: contact gdb-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-owner@sourceware.org Received: (qmail 45008 invoked by uid 89); 6 Feb 2020 22:06:18 -0000 Authentication-Results: sourceware.org; auth=none X-Spam-SWARE-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00,RCVD_IN_DNSWL_LOW,SPF_PASS autolearn=ham version=3.3.1 spammy=stl X-HELO: eggs.gnu.org Received: from eggs.gnu.org (HELO eggs.gnu.org) (209.51.188.92) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Thu, 06 Feb 2020 22:06:16 +0000 Received: from fencepost.gnu.org ([2001:470:142:3::e]:57330) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1izpHq-00012m-NS for gdb@sourceware.org; Thu, 06 Feb 2020 17:06:14 -0500 Received: from pool-98-118-0-140.bstnma.fios.verizon.net ([98.118.0.140]:42754 helo=homebase.home) by fencepost.gnu.org with esmtpsa (TLS1.2:RSA_AES_256_CBC_SHA1:256) (Exim 4.82) (envelope-from ) id 1izpHQ-0007H2-Di for gdb@sourceware.org; Thu, 06 Feb 2020 17:05:50 -0500 Message-ID: <2a0eff24d5b58db30efc9d8a16b256f4748d0071.camel@gnu.org> Subject: Debugging in multithreaded systems From: Paul Smith Reply-To: psmith@gnu.org To: gdb@sourceware.org Date: Thu, 06 Feb 2020 22:06:00 -0000 Content-Type: text/plain; charset="UTF-8" User-Agent: Evolution 3.34.1-2 MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic] X-IsSubscribed: yes X-SW-Source: 2020-02/txt/msg00022.txt.bz2 Can someone provide some insight on multithreaded debugging? I'm trying to track down a really gnarly issue in a multithreaded system. I really need to control the way threads run while I'm debugging. I'm using GDB 8.2.1 on a GNU/Linux (x86_64) system. I'm setting 'set scheduler-locking step', which I thought would do what I wanted: when I'm debugging only my thread under debug will run and other threads are suspended: this is critical for me because if other threads run they perturb the bug. The problem is that the docs say that "step" mode will keep other threads locked in "step" and will free them up for "continue", "until", and "finish". But the docs don't say anything about "next". I had assumed that "next" would work like "step", but it appears that instead it works like "finish" etc. and allows other threads to run :(. I sort of get it because "next" is akin to stepping into a method then calling "finish", but this is a big bummer because I'm debugging a C++ program and trying to step through every STL statement in every method, etc. etc. is very time consuming. Abstractly it would make much more sense (to me) if "next" worked like "step" and kept the other threads locked out. Am I missing something? Is "next" supposed to work like "step"? If not could it be changed to do so? Or, I guess, if there really is some useful reason to have "next" allow other threads to run, a new scheduler-locking mode for "next" could be added...? For now I guess I'll (try to remember to) force "set scheduler-locking off" and then back on again by hand each time.