[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: ICU / NSDateFormatter crash
From: |
David Chisnall |
Subject: |
Re: ICU / NSDateFormatter crash |
Date: |
Fri, 28 Jul 2017 08:24:15 +0100 |
> 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