Hi Richard, On Friday, 2014-12-19 14:18:36 +0100, Richard PALO wrote:
warn:vcl:101172:1:vcl/generic/fontmanager/fontconfig.cxx:868: In glyph fallback throwing away the language property of en because the detected script for '0x9f 3' is Bengali and that language doesn't make sense. Autodetecting instead.
That warning is only indirectly related because something may trigger initialization of liblangtag for an unknown locale value, I've seen it without any crash. Adapted subject..
My locale is fr_FR.UTF-8 on SunOS 5.11 under pkgsrc. it's coring with: sigmask = 0xffffbefc,0xffffffff,0x000001ff cursig = SIGSEGV Coredump indicates:08045fb8 libi18nlangtag.so`LiblantagDataRef::setup+0x4c(fe5b5bdc, fe5b5bdc, fe5b5a1c, 804605c) 08046128 libi18nlangtag.so`LanguageTagImpl::canonicalize+0x784(e34a900, 0, fe59b58b, fe5b28bc)
That is the actual top of the backtrace?
There isn't much in i18nlangtag/source/languagetag/languagetag.cxx
LiblantagDataRef::setup() that could go wrong. The only thing that comes
to mind is that LiblantagDataRef is a static instance initialized with
namespace {
struct theDataRef : public rtl::Static< LiblantagDataRef, theDataRef > {};
}
which for some reason may not work on SunOS / your compiler combination.
As probably no one is using that here, you'd have to break in
LanguageTagImpl::canonicalize() line 1204 where
theDataRef::get().incRef() is called (or in the
LiblantagDataRef::incRef() inline) and investigate what actually happens
the very first time when the incRef() calls setup()
Other than that maybe the lt_db_initialize() call misbehaves, but since
that is not in the backtrace..
However, only a step-through could provide insights.
Eike
--
LibreOffice Calc developer. Number formatter stricken i18n transpositionizer.
GPG key "ID" 0x65632D3A - 2265 D7F3 A7B0 95CC 3918 630B 6A6C D5B7 6563 2D3A
Better use 64-bit 0x6A6CD5B765632D3A here is why: https://evil32.com/
Care about Free Software, support the FSFE https://fsfe.org/support/?erack
Attachment:
pgpVDI6pC0HzF.pgp
Description: PGP signature