[lsb-discuss] what is the current libchk status in LSB 4.0 and 4.1?
Karel Srot
ksrot at redhat.com
Thu May 16 12:05:16 UTC 2013
Hi,
I am forwarding a feedback from our engineer Benjamin Kosnik regarding
similar failure
Message from the test:
Symbol address found for Virtual table entry [0][1] 0xfff86ae4bf8 (found) doesn't match 0xfff86ae4c08 (expected)
Virtual Function[0][1] NULL or _ZNSt21__ctype_abstract_baseIcED0Ev (expected) doesn't match _ZNSt14collate_bynameIcED0Ev (found)
Unmangled expected: std::__ctype_abstract_base<char>::~__ctype_abstract_base()
Unmangled found...: std::collate_byname<char>::~collate_byname()
[!!!] Unqualified function names do not match:
(expected) ~__ctype_abstract_base()
(.found..) ~collate_byname()
Test Purpose Comment: _ZSt21__ctype_abstract_baseIcE virtual function pointers
This is very problematic, in that std::__ctype_abstract_base<char> is never instantiated by user or library code. Instead, the std::ctype<char> class is derived from std::locale::facet, and std::ctype_base.
If you're wondering, "hey, does this libstdc++.so have a std::ctype<char> facet that works?" Well then, the answer is in libstdc++-v3/testsuite/22_locale/ctype*. This is part of "make check" in the gcc package, so if there are fails there then be concerned. And the same for codecvt, in libstdc++-v3/testsuite/22_locale/codecvt*.
Instead, this testsuite is looking at libstdc++ exports. In fact, there is a vtable emitted for std::ctype<char>, due to the use of "inline template" explicit instantiations in src/locale-inst.cc. This I consider a build/versioning oversight/mistake that now must be maintained for ABI compat.
But you want to verify on a built machine.
You can re-make the file with the vtables (locale-inst.o), and instrument it as follows:
cd LIBCXXBLD/src/c++98;
make CXXFLAGS="-g -O2 -fdump-class-hierarchy" locale-inst.o
then, look at the generated files:
locale-inst.o
locale-inst.cc.002t.class
In the .class file, look for:
Vtable for std::ctype<char>
std::ctype<char>::_ZTVSt5ctypeIcE: 12u entries
0 (int (*)(...))0
8 (int (*)(...))(& _ZTISt5ctypeIcE)
16 (int (*)(...))std::ctype<char>::~ctype
24 (int (*)(...))std::ctype<char>::~ctype
32 (int (*)(...))std::ctype<char>::do_toupper
40 (int (*)(...))std::ctype<char>::do_toupper
48 (int (*)(...))std::ctype<char>::do_tolower
56 (int (*)(...))std::ctype<char>::do_tolower
64 (int (*)(...))std::ctype<char>::do_widen
72 (int (*)(...))std::ctype<char>::do_widen
80 (int (*)(...))std::ctype<char>::do_narrow
88 (int (*)(...))std::ctype<char>::do_narrow
and
Vtable for std::__ctype_abstract_base<wchar_t>
std::__ctype_abstract_base<wchar_t>::_ZTVSt21__ctype_abstract_baseIwE: 16u entries
0 (int (*)(...))0
8 (int (*)(...))(& _ZTISt21__ctype_abstract_baseIwE)
16 (int (*)(...))std::__ctype_abstract_base<_CharT>::~__ctype_abstract_base<wchar_t>
24 (int (*)(...))std::__ctype_abstract_base<_CharT>::~__ctype_abstract_base<wchar_t>
32 (int (*)(...))__cxa_pure_virtual
40 (int (*)(...))__cxa_pure_virtual
48 (int (*)(...))__cxa_pure_virtual
56 (int (*)(...))__cxa_pure_virtual
64 (int (*)(...))__cxa_pure_virtual
72 (int (*)(...))__cxa_pure_virtual
80 (int (*)(...))__cxa_pure_virtual
88 (int (*)(...))__cxa_pure_virtual
96 (int (*)(...))__cxa_pure_virtual
104 (int (*)(...))__cxa_pure_virtual
112 (int (*)(...))__cxa_pure_virtual
120 (int (*)(...))__cxa_pure_virtual
Vtable for std::ctype<wchar_t>
std::ctype<wchar_t>::_ZTVSt5ctypeIwE: 16u entries
0 (int (*)(...))0
8 (int (*)(...))(& _ZTISt5ctypeIwE)
16 (int (*)(...))std::ctype<wchar_t>::~ctype
24 (int (*)(...))std::ctype<wchar_t>::~ctype
32 (int (*)(...))std::ctype<wchar_t>::do_is
40 (int (*)(...))std::ctype<wchar_t>::do_is
48 (int (*)(...))std::ctype<wchar_t>::do_scan_is
56 (int (*)(...))std::ctype<wchar_t>::do_scan_not
64 (int (*)(...))std::ctype<wchar_t>::do_toupper
72 (int (*)(...))std::ctype<wchar_t>::do_toupper
80 (int (*)(...))std::ctype<wchar_t>::do_tolower
88 (int (*)(...))std::ctype<wchar_t>::do_tolower
96 (int (*)(...))std::ctype<wchar_t>::do_widen
104 (int (*)(...))std::ctype<wchar_t>::do_widen
112 (int (*)(...))std::ctype<wchar_t>::do_narrow
120 (int (*)(...))std::ctype<wchar_t>::do_narrow
and
Vtable for std::codecvt<char, char, __mbstate_t>
std::codecvt<char, char, __mbstate_t>::_ZTVSt7codecvtIcc11__mbstate_tE: 11u entries
0 (int (*)(...))0
8 (int (*)(...))(& _ZTISt7codecvtIcc11__mbstate_tE)
16 (int (*)(...))std::codecvt<char, char, __mbstate_t>::~codecvt
24 (int (*)(...))std::codecvt<char, char, __mbstate_t>::~codecvt
32 (int (*)(...))std::codecvt<char, char, __mbstate_t>::do_out
40 (int (*)(...))std::codecvt<char, char, __mbstate_t>::do_unshift
48 (int (*)(...))std::codecvt<char, char, __mbstate_t>::do_in
56 (int (*)(...))std::codecvt<char, char, __mbstate_t>::do_encoding
64 (int (*)(...))std::codecvt<char, char, __mbstate_t>::do_always_noconv
72 (int (*)(...))std::codecvt<char, char, __mbstate_t>::do_length
80 (int (*)(...))std::codecvt<char, char, __mbstate_t>::do_max_length
Vtable for std::codecvt<wchar_t, char, __mbstate_t>
std::codecvt<wchar_t, char, __mbstate_t>::_ZTVSt7codecvtIwc11__mbstate_tE: 11u entries
0 (int (*)(...))0
8 (int (*)(...))(& _ZTISt7codecvtIwc11__mbstate_tE)
16 (int (*)(...))std::codecvt<wchar_t, char, __mbstate_t>::~codecvt
24 (int (*)(...))std::codecvt<wchar_t, char, __mbstate_t>::~codecvt
32 (int (*)(...))std::codecvt<wchar_t, char, __mbstate_t>::do_out
40 (int (*)(...))std::codecvt<wchar_t, char, __mbstate_t>::do_unshift
48 (int (*)(...))std::codecvt<wchar_t, char, __mbstate_t>::do_in
56 (int (*)(...))std::codecvt<wchar_t, char, __mbstate_t>::do_encoding
64 (int (*)(...))std::codecvt<wchar_t, char, __mbstate_t>::do_always_noconv
72 (int (*)(...))std::codecvt<wchar_t, char, __mbstate_t>::do_length
80 (int (*)(...))std::codecvt<wchar_t, char, __mbstate_t>::do_max_length
On Wed, 2013-05-15 at 16:26 -0400, Jeff Licquia wrote:
> On 05/07/2013 06:03 AM, Karel Srot wrote:
> > I am sending journals for rhel-6.0 and rhel-6.4 with various lsb-libchk
> > versions. See the attached archive.
> > Thank you.
>
> Thanks. I've ended up sending a link to those to bug 3602, so that we
> can keep all this together.
>
> From my initial analysis, this looks different from the problem with
> compatible vtable changes in libchk; it looks more like the vtable
> itself has shifted in the library. But I expect Red Hat isn't seeing
> the wholesale breakage of C++ apps such a shift would imply, so I'm
> wondering if there's a counting bug or some such in libchk.
Karel
--
Karel Srot
Quality Engineer, QE BaseOS Security team
Email: ksrot at redhat.com
Web: www.cz.redhat.com
Red Hat Czech s.r.o., Purkyňova 99/71, 612 45, Brno, Czech Republic
More information about the lsb-discuss
mailing list