From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 48843 invoked by alias); 5 Nov 2017 22:01:40 -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 48833 invoked by uid 89); 5 Nov 2017 22:01:40 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: =?ISO-8859-1?Q?No, score=2.8 required=5.0 tests=AWL,BAYES_00,BODY_8BITS,GARBLED_BODY,KAM_LAZY_DOMAIN_SECURITY,RCVD_IN_DNSWL_NONE autolearn=no version=3.3.2 spammy=H*UA:iPad, H*x:iPad, painful, =ac=e4=ba=ae?= X-HELO: p3plsmtpa12-04.prod.phx3.secureserver.net Received: from p3plsmtpa12-04.prod.phx3.secureserver.net (HELO p3plsmtpa12-04.prod.phx3.secureserver.net) (68.178.252.233) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Sun, 05 Nov 2017 22:01:39 +0000 Received: from [10.0.0.3] ([172.14.36.47]) by :SMTPAUTH: with SMTP id BSz0efii0plXtBSz3e1rfR; Sun, 05 Nov 2017 15:01:37 -0700 Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (1.0) Subject: Re: why does assert(0) corrupt the stack trace? From: Duane Ellis In-Reply-To: Date: Sun, 05 Nov 2017 22:01:00 -0000 Cc: Jan Kratochvil , gdb@sourceware.org Content-Transfer-Encoding: quoted-printable Message-Id: References: <20171105195410.GA29185@host1.jankratochvil.net> To: =?utf-8?B?5oWV5Yas5Lqu?= X-CMAE-Envelope: MS4wfIYoSw7we1EPqMu6SjsGCH8v73dFAnvQPJ0n8L979gvHHfkxAmooA4VGpTdluQpy3HsTWVtWbe3nyq+nRpC3zNEjktxE5CrzUC9S0Q90GDx0s20CCRds 4ZL3iC7+7+WuDiL+NFJuLw+QZW5cAKGVtEwXSwpZ2UEWqpB+po7R9UuA43H2CpfV8VJcMjw1jFbeH/Xhm114ogYS0t9L4dcN4tfDdhJQ7wf+APNNp1NEf46e Nb/tOCbUoa1v+U33AvNhfw== X-IsSubscribed: yes X-SW-Source: 2017-11/txt/msg00005.txt.bz2 > On Nov 5, 2017, at 12:05 PM, =E6=85=95=E5=86=AC=E4=BA=AE wrote: >=20 > If I compile the program with "-O0", this problem may be solved. Yes? Often with =E2=80=9C-O0=E2=80=9D (dash OH zero, turning the optimizer off) = helps this is the most direct route to try to determine what went wrong. However - it depends on what went wrong, for example if your application ha= s a buffer overflow on the stack, and that buffer overflow corrupted the st= ack - or other memory was corrupted the stack back trace might as a result = be corrupt Or - the problem might change/move when you disable the optimizer the code = changes, the number of registers allocated per function changes, etc ...=20 That said, the most direct and most common thing to do is to disable the op= timizer and try again. If you get desperate and the above does not help you might try unwinding th= e stack by hand - it takes a while and often you can do what the compiler &= debugger cannot do. This approach trys to understand where the application was, and what it was= doing when the crash occurred - sometimes you can inspect memory at or nea= r the stack, and manually unwind the stack by inspecting various values sto= red on the stack. For example, on a 32bit machine - dump the stack memory near the stack poin= ter (ie: +/- 512 bytes) as 32bit values - then look at each value and see i= f they align with addresses within your application where subroutine calls = occur. (Ie: Use =E2=80=9Cobjdump -d MYAPP=E2=80=9D to get a disassembly l= isting of your app) It is painful but sometimes it is the only way. -Duane.