[Libreoffice-bugs] [Bug 52539] New: : TypeInfoHelper::getClassName() may crash if cppunit is compiled with older compiler

[bugzilla-daemon at freedesktop.org]

https://bugs.freedesktop.org/show_bug.cgi?id=52539

             Bug #: 52539
           Summary: : TypeInfoHelper::getClassName() may crash if cppunit
                    is compiled with older compiler
    Classification: Unclassified
           Product: LibreOffice
           Version: unspecified
          Platform: Other
        OS/Version: All
            Status: UNCONFIRMED
 Status Whiteboard: BSA
          Severity: normal
          Priority: medium
         Component: Libreoffice
        AssignedTo: libreoffice-bugs at lists.freedesktop.org
        ReportedBy: avg at icyb.net.ua


Created attachment 64731
  --> https://bugs.freedesktop.org/attachment.cgi?id=64731
proposed patch

It seems that GCC ABI compatibility is not strict enough and has a hidden
"gem".  TypeInfoHelper::getClassName() method may produce a crash of cppunit
library is compiled with older GCC (e.g. GCC 4.2) and the method is used to
inquire information about code produced with newer GCC (e.g. GCC 4.6).
Note that there would not be any ABI incompatibilities detected at link time or
run-time, but the code would crash.

Let's try to unravel this issue step by step.
The crash happens because of std::logic_error exception with what being
"basic_string::_S_construct NULL".

This exception happens when an std::string is constructed from a NULL C-string.

According to a backtrace that I obtained the exception is triggered in
src/cppunit/TypeInfoHelper.cpp, TypeInfoHelper::getClassName() method, at the
following lines:

  c_name = abi::__cxa_demangle( info.name(), 0, 0, &status );

  std::string name( c_name );

The immediate cause of the crash is that the cppunit code doesn't verify
neither status produced by abi::__cxa_demangle nor its return value.  In other
words, the code doesn't expect that abi::__cxa_demangle may fail and doesn't
properly handle its failure.
This could be considered a bug on its own.
In general std::type_info::name() is not supposed to a return a name that
abi::__cxa_demangle would not understand.  But it's still better to be on the
safe side and produce useful diagnostics if something goes wrong.

In my environment I determined that depending on a compiler used to compile the
cppunit library std::type_info::name() returns either "*N12_GLOBAL__N_14TestE"
for gcc 4.2 or
"N12_GLOBAL__N_14TestE" for 4.6 (without the leading asterisk) in the test
where the crash happens.

The mangled name with the leading asterisk is not valid according to C++ ABI,
but it is produced by GCC 4.6.

It seems that GCC 4.6 uses that leading asterisk for some internal purposed and
it is supposed to be hidden/ignored.

Unfortunately, it seems that std::type_info::name() is an inline method and
thus it can not be really used to guarantee ABI compatibility across GCC
versions.
To show what I mean here is how std::type_info::name() is implemented in GCC
4.2:
    const char* name() const
    { return __name; }
Now the same from GCC 4.6:
    const char* name() const
    { return __name[0] == '*' ? __name + 1 : __name; }

So, as we can see, the later GCC knows about the asterisk and hides it from
callers.  GCC 4.2 doesn't know about it and so it returns __name as is.  Due to
inlining the code compiled by GCC 4.2 may incorrectly return typeinfo::name for
code compiled with GCC 4.6.
If std::type_info::name() was not inlined, then a version from libstdc++ would
be used and it would be impossible to call the 4.2 version while dealing with
4.6 code.

So this is the trigger of the problem.  The attached patch could be used to
work around the problem by applying the same logic as type_info::name() in GCC
4.6 uses.

The patch doesn't add error handling that I mentioned above.

-- 
Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.