Re: ICU / NSDateFormatter crash

[David Chisnall]

On 12 Jul 2017, at 22:35, Riccardo Mottola <address@hidden> 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=<optimized out>,
>    _cmd=0x81532d0 <_OBJC_SELECTOR_TABLE+1488>) at FModuleCrDate.m:142
> 142         formatter = [[NSDateFormatter alloc] initWithDateFormat: @"%m %d 
> %Y"
> 
> Riccardo
> 
> 
> #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

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