Re: ICU / NSDateFormatter crash

[David Chisnall]

> On 28 Jul 2017, at 01:18, Riccardo Mottola <address@hidden> wrote:
> 
> Hi,
> 
> David Chisnall wrote:
>> This is quite surprising.  On FreeBSD, this function should be provided by 
>> libcxxrt, not libsupc++.  Please file a bug report with the FreeBSD gcc 
>> maintainer - it looks as if you’ve somehow ended up with a program linking 
>> both libc++ from base and libstdc++ from ports, and the libstdc++ from ports 
>> is incorrectly using its own internal libsupc++ instead of the 
>> system-provided libcxxrt (which I wrote, so can help debugging a bit better).
>> 
>> That said, this function should not crash.  It should only do so if the 
>> object that is being passed to it is invalid.  Is  0x2e904a80 a valid 
>> address of an icu::UObject?
> 
> how can I know?

Inspect it in gdb / lldb?  I think icu::UObject has a vtable, so you should be 
able to cast it to UObject and dump it and see if it looks sensible.

>> The crash calling a null function pointer looks a bit suspicious, because 
>> the only function pointers invoked by this function should be from the 
>> typeinfo object’s vtable, and should never be null.  There was an ABI break 
>> for the layout of typeinfo vtables from gcc a while ago and I don’t remember 
>> which one FreeBSD ended up with, but if you’re linking both libcxxrt and 
>> libsupc++ then you may end up with this.
> 
> that's unfortunate. It took me a while to respond, because I notived a minor 
> update in the GCC 5 package and updated to it (I do through compilation on my 
> own using portupgrade). I also updated other things.
> 
> #0  0x00000000 in ?? ()
> #1  0x29c0ad42 in __cxxabiv1::__dynamic_cast (src_ptr=0x2e904a80,
>    src_type=0x2973c618 <typeinfo for icu::UObject>,
>    dst_type=0x2973d8b8 <typeinfo for icu::UnicodeString>, src2dst=0)
>    at /usr/ports/lang/gcc5/work/gcc-5.4.0/libstdc++-v3/libsupc++/dyncast.cc:72
> #2  0x2942d51d in icu::Calendar::makeInstance(icu::Locale const&, UErrorCode&)
>    () from /usr/local/lib/libicui18n.so.58
> #3  0x2942d3ba in icu::LocaleCacheKey<icu::SharedCalendar>::createObject(void 
> const*, UErrorCode&) const () from /usr/local/lib/libicui18n.so.58
> #4  0x296d190f in icu::UnifiedCache::_get(icu::CacheKeyBase const&, 
> icu::SharedObject const*&, void const*, UErrorCode&) const ()
>   from /usr/local/lib/libicuuc.so.58
> #5  0x29438906 in void 
> icu::UnifiedCache::get<icu::SharedCalendar>(icu::CacheKey<icu::SharedCalendar>
>  const&, void const*, icu::SharedCalendar const*&, UErrorCode&) const () from 
> /usr/local/lib/libicui18n.so.58
> #6  0x29437d78 in void 
> icu::UnifiedCache::getByLocale<icu::SharedCalendar>(icu::Locale const&, 
> icu::SharedCalendar const*&, UErrorCode&) ()
>   from /usr/local/lib/libicui18n.so.58
> #7  0x2942e90d in icu::Calendar::createInstance(icu::TimeZone*, icu::Locale 
> const&, UErrorCode&) () from /usr/local/lib/libicui18n.so.58
> #8  0x293ec0f1 in icu::SimpleDateFormat::construct(icu::DateFormat::EStyle, 
> icu::DateFormat::EStyle, icu::Locale const&, UErrorCode&) ()
>   from /usr/local/lib/libicui18n.so.58
> 
> 
> Thre crash is still in place and it is still using libsupc++
> 
> Do you want more information of the stacktrace or should I just file a bug 
> right away?

Calling out to libsupc++ is definitely a bug in the gcc port - it should not be 
linking libsupc++ at all.  That might not be the root cause of this bug though. 
 You would see a crash like this if the object at 0x2973c618 had been 
deallocated.  It might be worth checking which Objective-C object owns the ICU 
objects and whether it has accidentally been deallocated.

David