This is the mail archive of the
gdb@sourceware.org
mailing list for the GDB project.
Re: why does assert(0) corrupt the stack trace?
- From: Jan Kratochvil <jan dot kratochvil at redhat dot com>
- To: 慕冬亮 <mudongliangabcd at gmail dot com>
- Cc: gdb at sourceware dot org
- Date: Sun, 5 Nov 2017 20:54:10 +0100
- Subject: Re: why does assert(0) corrupt the stack trace?
- Authentication-results: sourceware.org; auth=none
- Authentication-results: ext-mx06.extmail.prod.ext.phx2.redhat.com; dmarc=none (p=none dis=none) header.from=redhat.com
- Authentication-results: ext-mx06.extmail.prod.ext.phx2.redhat.com; spf=fail smtp.mailfrom=jan dot kratochvil at redhat dot com
- Dmarc-filter: OpenDMARC Filter v1.3.2 mx1.redhat.com B3D49356F7
- References: <CAD-N9QVbDJNJXrnsS3PNTvRXvvUK=pB6f+Gpj4WGTSjMoYR9pg@mail.gmail.com>
On Sun, 05 Nov 2017 20:13:20 +0100, 慕冬亮 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 where
to return.
It was some intermediate development phase where such optimization was created
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