Co ugryzło LibreOffice?

[Pawel Sikora]

On Thursday 02 of June 2011 17:09:39 Arkadiusz Miskiewicz wrote:
> On Thursday 02 of June 2011, Łukasz Maśko wrote:
> > Dnia czwartek, 2 czerwca 2011, Łukasz Maśko napisał:
> > [...]
> > 
> > > Dowolny składnik LibreOffice uruchamiany z linii polceń _bez_żadnego_
> > > pliku do otwarcia powoduje poprawne uruchomienie aplikacja się i jeśli
> > > jest już otwarta, to można z niej otworzyć dowolny dokument. I wtedy
> > > jest OK.
> > 
> > Dodam jeszcze, że próba otworzenia drugiego, dowolnego dokumentu równolegle
> > do jakiegoś już otwartego oznacza natychmiastowy segfault. I to samo
> > występuje na 2 maszynach, którymi dysponuję.
> 
> U mnie na x86_64 nic złego się nie dzieje w opisanych scenariuszach. i686 mogę 
> przetestować w pon dopiero.
> 

u mnie na x86_64 (up-to-date) proba otwarcia .ppt konczy sie tak:

Program received signal SIGSEGV, Segmentation fault.
0x00007fcd2e391fd1 in do_lookup_x (new_hash=1970759491, old_hash=0x7fff79955d58, result=0x7fff79955d40, scope=<value optimized out>, i=0, flags=2, skip=0x0, undef_map=0x7fcd2e58a000) at dl-lookup.c:98
98            const struct link_map *map = list[i]->l_real;
(gdb) bt
#0  0x00007fcd2e391fd1 in do_lookup_x (new_hash=1970759491, old_hash=0x7fff79955d58, result=0x7fff79955d40, scope=<value optimized out>, i=0, flags=2, skip=0x0, undef_map=0x7fcd2e58a000) at dl-lookup.c:98
#1  0x00007fcd2e392922 in _dl_lookup_symbol_x (undef_name=0x13a5758 "component_getImplementationEnvironmentExt", undef_map=0x7fcd2e58a000, ref=0x7fff79955e20, symbol_scope=0x7fcd2e58a388, version=0x0, 
    type_class=0, flags=2, skip_map=0x0) at dl-lookup.c:739
#2  0x00007fcd2d3065d5 in do_sym (handle=<value optimized out>, name=0x13a5758 "component_getImplementationEnvironmentExt", who=<value optimized out>, vers=<value optimized out>, flags=2) at dl-sym.c:177
#3  0x00007fcd2cff0074 in dlsym_doit (a=0x7fff79955fd0) at dlsym.c:51
#4  0x00007fcd2e396b66 in _dl_catch_error (objname=0x608390, errstring=0x608398, mallocedp=0x608388, operate=0x7fcd2cff0060 <dlsym_doit>, args=0x7fff79955fd0) at dl-error.c:178
#5  0x00007fcd2cff04ec in _dlerror_run (operate=0x7fcd2cff0060 <dlsym_doit>, args=0x7fff79955fd0) at dlerror.c:164
#6  0x00007fcd2cff00ca in __dlsym (handle=<value optimized out>, name=<value optimized out>) at dlsym.c:71
#7  0x00007fcd2dfc4ce6 in osl_getFunctionSymbol () from /usr/lib64/libreoffice/program/../basis-link/ure-link/lib/libuno_sal.so.3
#8  0x00007fcd2c80ae9f in ?? () from /usr/lib64/libreoffice/program/../basis-link/program/../ure-link/lib/libuno_cppuhelpergcc3.so.3
#9  0x00007fcd2c80cabc in cppu::loadSharedLibComponentFactory(rtl::OUString const&, rtl::OUString const&, rtl::OUString const&, com::sun::star::uno::Reference<com::sun::star::lang::XMultiServiceFactory> const&, com::sun::star::uno::Reference<com::sun::star::registry::XRegistryKey> const&) () from /usr/lib64/libreoffice/program/../basis-link/program/../ure-link/lib/libuno_cppuhelpergcc3.so.3
(...)

nie sprawdzalem czy to przypadkiem glibc-2.14 nie wywinal jakiegos numeru bo aktualnie mam co robic :)