>Number: 2384
>Category: c++
>Synopsis: dangling pointer in TYPE_VPTR_BASETYPE when baseclass is in
>shared object
>Confidential: no
>Severity: serious
>Priority: medium
>Responsible: unassigned
>State: open
>Class: sw-bug
>Submitter-Id: net
>Arrival-Date: Thu Dec 13 23:38:01 UTC 2007
>Closed-Date:
>Last-Modified:
>Originator: dje@xxxxxxxxxx
>Release: 6.7.1
>Organization:
>Environment:
i386-linux
>Description:
The appended exampled illustrates a problem in gdb's handling of baseclasses in
shared libraries. When gdb resolves type information for class "derived" from
objfile base-in-so.x, it fills in the TYPE_VPTR_BASETYPE field with class
"base" from objfile base-in-so-base.so. When the program is rerun the type
information for base-in-so-base.so is discarded leaving TYPE_VPTR_BASETYPE
dangling.
>How-To-Repeat:
g++ -g -shared base-in-so-base.cc -o base-in-so-base.so
g++ -g base-in-so.cc -o base-in-so.x -Wl,-rpath,`pwd` base-in-so-base.so
gdb base-in-so.x
break base-in-so.cc:20
run
[hits breakpoint]
print d.meth()
$1 = 42
run
Start at beginning? y
[hits breakpoint]
print d.meth()
--> segv
If the program doesn't hit a segv, it may just be that gdb got lucky. Putting
in an assert will show the issue too:
--- gdbtypes.c~ 2007-12-13 15:20:59.062220000 -0800
+++ gdbtypes.c 2007-12-13 15:21:39.408302000 -0800
@@ -1307,6 +1307,7 @@ fill_in_vptr_fieldno (struct type *type)
fill_in_vptr_fieldno (baseclass);
if (TYPE_VPTR_FIELDNO (baseclass) >= 0)
{
+ gdb_assert (TYPE_OBJFILE (type) == TYPE_OBJFILE (baseclass));
TYPE_VPTR_FIELDNO (type) = TYPE_VPTR_FIELDNO (baseclass);
TYPE_VPTR_BASETYPE (type) = TYPE_VPTR_BASETYPE (baseclass);
break;
>Fix:
>Release-Note:
>Audit-Trail:
>Unformatted:
----gnatsweb-attachment----
Content-Type: application/octet-stream; name="base-in-so-segv.example"
Content-Transfer-Encoding: base64
Content-Disposition: attachment; filename="base-in-so-segv.example"
LS0tIC9kZXYvbnVsbAkyMDA2LTA1LTIyIDA3OjI1OjIzLjAwMDAwMDAwMCAtMDcwMAorKysgYmFz
ZS1pbi1zby5jYwkyMDA3LTEyLTEzIDE0OjU0OjI3LjcxODUxNDAwMCAtMDgwMApAQCAtMCwwICsx
LDIyIEBACisjaW5jbHVkZSAiYmFzZS1pbi1zby1iYXNlLmgiCisKK2NsYXNzIGRlcml2ZWQgOiBw
dWJsaWMgYmFzZQoreworIHB1YmxpYzoKKyAgZGVyaXZlZCAoaW50KTsKK307CisKK2Rlcml2ZWQ6
OmRlcml2ZWQgKGludCBfeCkKKyAgOiBiYXNlIChfeCkKK3sKK30KKworaW50IGc7CisKK2ludAor
bWFpbiAoKQoreworICBkZXJpdmVkIGQgKDQyKTsKKyAgZyA9IGQubWV0aCAoKTsgLy8gc2V0IGJy
ZWFrcG9pbnQgaGVyZQorICByZXR1cm4gMDsKK30KLS0tIC9kZXYvbnVsbAkyMDA2LTA1LTIyIDA3
OjI1OjIzLjAwMDAwMDAwMCAtMDcwMAorKysgYmFzZS1pbi1zby1iYXNlLmgJMjAwNy0xMi0xMyAx
NDo1NDoyNy43MTc1MDgwMDAgLTA4MDAKQEAgLTAsMCArMSw3IEBACitjbGFzcyBiYXNlCit7Cisg
cHVibGljOgorICBiYXNlIChpbnQgX3gpOworICBpbnQgeDsKKyAgdmlydHVhbCBpbnQgbWV0aCAo
KTsKK307Ci0tLSAvZGV2L251bGwJMjAwNi0wNS0yMiAwNzoyNToyMy4wMDAwMDAwMDAgLTA3MDAK
KysrIGJhc2UtaW4tc28tYmFzZS5jYwkyMDA3LTEyLTEzIDE0OjU0OjI3LjcxNDUxNzAwMCAtMDgw
MApAQCAtMCwwICsxLDEyIEBACisjaW5jbHVkZSAiYmFzZS1pbi1zby1iYXNlLmgiCisKK2Jhc2U6
OmJhc2UgKGludCBfeCkKKyAgOiB4IChfeCkKK3sKK30KKworaW50CitiYXNlOjptZXRoICgpCit7
CisgIHJldHVybiB4OworfQo=
|
