c++/2384: dangling pointer in TYPE_VPTR_BASETYPE when baseclass is in shared object

[dje at google dot com]

>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@google.com
>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=