> On 28 Jul 2017, at 01:18, Riccardo Mottola <riccardo.mott...@libero.it> 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 _______________________________________________ Gnustep-dev mailing list Gnustep-dev@gnu.org https://lists.gnu.org/mailman/listinfo/gnustep-dev