From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 112273 invoked by alias); 5 Nov 2017 20:05:38 -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 112258 invoked by uid 89); 5 Nov 2017 20:05:38 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=2.3 required=5.0 tests=AWL,BAYES_00,BODY_8BITS,FREEMAIL_FROM,GARBLED_BODY,RCVD_IN_DNSWL_NONE,RCVD_IN_SORBS_SPAM,SPF_PASS autolearn=no version=3.3.2 spammy=safe!, Hx-spam-relays-external:sk:mail-ua, HX-HELO:sk:mail-ua, dongliang X-HELO: mail-ua0-f174.google.com Received: from mail-ua0-f174.google.com (HELO mail-ua0-f174.google.com) (209.85.217.174) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Sun, 05 Nov 2017 20:05:36 +0000 Received: by mail-ua0-f174.google.com with SMTP id n22so5104414uaj.13 for ; Sun, 05 Nov 2017 12:05:36 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-transfer-encoding; bh=3B2/DwCAQaM8DPrwHcPsp5LZdKi3ULwkYgSvgXWtDeY=; b=t7nMx87SjVfSIBhSad2YxphZzDwiCFX6qB3QNSEMvkKQAoTIHDCeLnkFnF78zhpRm8 IKpiNpWukixhCC7hU47B7CPVWI9PkDq/rO4TJhRlqTW1dsPHpbtuaF3U6LNY68xHZKfE rNWPxwPOl8nnvGd4TU8PLCLPL+eSY/chwUufWqickhb2v248IMSYJlIF/ki2AghtsgJS nzR6yhHAmiY+Cu4TH/Z9DR0JGGwOWxN2Q6wPQbWGKKBRWP7eepjCx9RsN+RIdngPX1SU 459t8OcXfHlIKIXgUaVErNFDK0D1tIBf726kxJu7qf9kl8p5wX4HkPlfEivzD7ifSa1M IiyQ== X-Gm-Message-State: AMCzsaXigFDG+bzwPdy03Q/0fx1UxrTsJfwvmEPrl0IsMxunncYi/VO8 6eLUoypgXZBvIRTYmYVUXsZfLDf0s30rEDwLN3Q= X-Google-Smtp-Source: ABhQp+SitpSi/r6tCCkFuptixRRKDyiInr+EguoYfK+Wwo8GzYXXbNzEkyT/mxF8A3xSXCpSRAn1EbAgWSuCo1fR6bU= X-Received: by 10.159.42.202 with SMTP id d10mr11007740uaj.74.1509912334863; Sun, 05 Nov 2017 12:05:34 -0800 (PST) MIME-Version: 1.0 Received: by 10.103.146.29 with HTTP; Sun, 5 Nov 2017 12:05:04 -0800 (PST) In-Reply-To: <20171105195410.GA29185@host1.jankratochvil.net> References: <20171105195410.GA29185@host1.jankratochvil.net> From: =?UTF-8?B?5oWV5Yas5Lqu?= Date: Sun, 05 Nov 2017 20:05:00 -0000 Message-ID: Subject: Re: why does assert(0) corrupt the stack trace? To: Jan Kratochvil Cc: gdb@sourceware.org Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-IsSubscribed: yes X-SW-Source: 2017-11/txt/msg00003.txt.bz2 -- My best regards to you. No System Is Safe! Dongliang Mu 2017-11-05 14:54 GMT-05:00 Jan Kratochvil : > On Sun, 05 Nov 2017 20:13:20 +0100, =E6=85=95=E5=86=AC=E4=BA=AE wrote: >> I have a question about debugging assert in gdb. When one program >> crash at one assert statement, the stack trace shown in the gdb is >> corrupted. Is it normal? > > It was happening in the past as when assert() detects a failure it calls > abort() which does never return - using GCC attribute noreturn. Then GCC > optimizer does not save enough registers to make the backtrace possible > because the code will just abort anyway, the code does not need to know w= here > to return. > If I compile the program with "-O0", this problem may be solved. Yes? > It was some intermediate development phase where such optimization was cr= eated > and before an exception has been made to make the backtracing by debuggers > possible. > > Sorry for not looking up the Bugs/commits. > > As usual you should update your compiler + debugger to latest versions. > > > Jan