[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


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:


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


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


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 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