This is the mail archive of the
gdb-prs@sources.redhat.com
mailing list for the GDB project.
gdb/521: gdb hangs when setting breakpoints, infinite loop in finish_cv_type
- From: mitch at lbcons dot net
- To: gdb-gnats at sources dot redhat dot com
- Date: 3 May 2002 10:01:57 -0000
- Subject: gdb/521: gdb hangs when setting breakpoints, infinite loop in finish_cv_type
- Reply-to: mitch at lbcons dot net
>Number: 521
>Category: gdb
>Synopsis: gdb hangs when setting breakpoints, infinite loop in finish_cv_type
>Confidential: no
>Severity: serious
>Priority: medium
>Responsible: unassigned
>State: open
>Class: sw-bug
>Submitter-Id: net
>Arrival-Date: Fri May 03 03:08:01 PDT 2002
>Closed-Date:
>Last-Modified:
>Originator: mitch@lbcons.net
>Release: 5.2
>Organization:
>Environment:
Linux altair 2.4.2 #15 Thu Oct 11 00:37:10 CEST 2001 i686 unknown
binutils 2.12.90.0.1-5
Reading specs from /usr/lib/gcc-lib/i386-linux/3.0.4/specs
Configured with: ../src/configure -v --enable-languages=c,c++,java,f77,proto,objc --prefix=/usr --infodir=/share/info --mandir=/share/man --enable-shared --with-gnu-as --with-gnu-ld --with-system-zlib --enable-long-long --enable-nls --without-included-gettext --disable-checking --enable-threads=posix --enable-java-gc=boehm --with-cpp-install-dir=bin --enable-objc-gc i386-linux
Thread model: posix
gcc version 3.0.4
GNU gdb 5.2
>Description:
gdb hangs when trying to set a breakpoint.
This is due to corrupted "struct type", which is
created with memcpy() in cleanup_undefined_types().
This memcpy() destroys the invariant, that TYPE_CV_TYPE
and TYPE_AS_TYPE rings are "rings", resulting in an
infinite loop in finish_cv_type().
The attached fix seems to solve this problem, although
I'd recommend a different approach to resolve undefined
types, one that avoids the memcpy() altogether:
I think you should create a "reference type" when you
find the defined type, and later when a request comes
for this (previously undefined) type, return instead
the refenced "struct type". this way the AS and CV rings
of the original type are preserved with this clone type
as well. Unfortunately I don't have enough understanding of the gdb codebase to implement this, nor the time to investigate further.
>How-To-Repeat:
The bug seems to occur only in some "unfortunate" situations, that our own code seems to trigger.
Unfortunately our codebase is proprietary, and I don't have
time to try and create a simple test case for it...
>Fix:
see attached patch.
patch applies to gdb 5.2 and current (as of 2002-05-03) CVS.
>Release-Note:
>Audit-Trail:
>Unformatted:
----gnatsweb-attachment----
Content-Type: application/octet-stream; name="gdb-clenup_undefined_types.patch"; name="gdb-clenup_undefined_types.patch"
Content-Transfer-Encoding: base64
Content-Disposition: attachment; filename="gdb-clenup_undefined_types.patch"
SW5kZXg6IGdkYi9zdGFic3JlYWQuYwo9PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09
PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09ClJDUyBmaWxlOiAvY3ZzL3NyYy9zcmMv
Z2RiL3N0YWJzcmVhZC5jLHYKcmV0cmlldmluZyByZXZpc2lvbiAxLjMwCmRpZmYgLXUgLXUgLXIx
LjMwIHN0YWJzcmVhZC5jCi0tLSBnZGIvc3RhYnNyZWFkLmMJMjEgTWFyIDIwMDIgMDA6NTM6NDQg
LTAwMDAJMS4zMAorKysgZ2RiL3N0YWJzcmVhZC5jCTMgTWF5IDIwMDIgMDk6NDc6NTAgLTAwMDAK
QEAgLTUwNjAsNiArNTA2MCw5IEBACiAJCQkgIHsKIAkJCSAgICBtZW1jcHkgKCp0eXBlLCBTWU1C
T0xfVFlQRSAoc3ltKSwKIAkJCQkgICAgc2l6ZW9mIChzdHJ1Y3QgdHlwZSkpOworCQkJICAgIC8q
IEZpeCBDViBhbmQgQVMgcmluZ3MuLi4gPG1pdGNoQGxiY29ucy5uZXQ+ICovCisJCQkgICAgVFlQ
RV9DVl9UWVBFICgqdHlwZSkgPSAqdHlwZTsKKwkJCSAgICBUWVBFX0FTX1RZUEUgKCp0eXBlKSA9
ICp0eXBlOwogCQkJICB9CiAJCSAgICAgIH0KIAkJICB9Cg==