Re: ICU / NSDateFormatter crash
On 12 Jul 2017, at 22:35, Riccardo Mottola wrote: > > Hi All, > > on FreeBSD with gcc5 and ICU I get a crash when starting up GWorkspace. > > A couple of weeks ago everything worked, this is the first big rebuild > (clean) since we transitioned to GIT I attempted. > > What could be wrong? > > stack 16 shows a sane value to me: > > #16 0x2c7cdb22 in -[FModuleCrDate initInterface] (self=, >_cmd=0x81532d0 <_OBJC_SELECTOR_TABLE+1488>) at FModuleCrDate.m:142 > 142 formatter = [[NSDateFormatter alloc] initWithDateFormat: @"%m %d > %Y" > > Riccardo > > > #0 0x in ?? () > #1 0x29c0ad42 in __cxxabiv1::__dynamic_cast (src_ptr=0x2e904a80, >src_type=0x2973c618 , >dst_type=0x2973d8b8 , src2dst=0) >at /usr/ports/lang/gcc5/work/gcc-5.4.0/libstdc++-v3/libsupc++/dyncast.cc:72 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? 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. David ___ Gnustep-dev mailing list Gnustep-dev@gnu.org https://lists.gnu.org/mailman/listinfo/gnustep-dev
Re: ICU / NSDateFormatter crash
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? 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 0x in ?? () #1 0x29c0ad42 in __cxxabiv1::__dynamic_cast (src_ptr=0x2e904a80, src_type=0x2973c618 , dst_type=0x2973d8b8 , 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::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::CacheKey const&, void const*, icu::SharedCalendar const*&, UErrorCode&) const () from /usr/local/lib/libicui18n.so.58 #6 0x29437d78 in void icu::UnifiedCache::getByLocale(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? This is a box running 10.3 and gcc5 is still "standard gcc from ports" as far as I know. I did try gcc6 a couple of months ago but it was non functional to compile gnustep... it was a mess, while gcc5 just worked fine (.except this issue, which I did not have a couple of months ago, but I don't know exactly what broke it) It could be April 1 commit by gerald :) Riccardo ___ Gnustep-dev mailing list Gnustep-dev@gnu.org https://lists.gnu.org/mailman/listinfo/gnustep-dev
Re: ICU / NSDateFormatter crash
> On 28 Jul 2017, at 01:18, Riccardo Mottola 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 0x in ?? () > #1 0x29c0ad42 in __cxxabiv1::__dynamic_cast (src_ptr=0x2e904a80, >src_type=0x2973c618 , >dst_type=0x2973d8b8 , 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::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::CacheKey > const&, void const*, icu::SharedCalendar const*&, UErrorCode&) const () from > /usr/local/lib/libicui18n.so.58 > #6 0x29437d78 in void > icu::UnifiedCache::getByLocale(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
