FYI:  I just experienced the exact same problem (regcomp spuriously successfully
registers vnd.openoffice.pymodule:pythonscript and then obviously crashes) on
unxlngi6 on a SRC680m213-based CWS (sb71).

I have never seen it on unxlngi6.pro and I did *lot* of builds there since m212 though.

I have not experienced this on any of the platforms (unxlngi6, wntmsci10,
unxsols4) I typically build. 

Pavel, if I understand correctly, you are seeing this on x86-64, so it seems I
need to upgrade one of the machines here ... ;-) By the way, can I still build
32bits e.g. on a x86-64 Ubuntu?

yes, you can build 32bit on 64bit, but you have to use Xen or linux32 to fake the environment and chroot.

.

->Pavel, I just build unomacli64 successfully on a Ubuntu 64bit box (note: the
fixes for i77422 are _not_ the ones I added as patches), because of some Java
problems, I did disable Java, which actually shouldn't be problem,.

I also tried to reproduce the failing regcomp by hand several times, without
success:
kr93794@x42-so23[466] /local/home/kr/unomacli64/instsetoo_native>
/local/home/kr/unomacli64/solver/680/unxlngx6.pro/bin/regcomp -register -br
/local/home/kr/unomacli64/solver/680/unxlngx6.pro/bin/types.rdb -br
/local/home/kr/unomacli64/solver/680/unxlngx6.pro/bin/pyuno_services.rdb -r
/tmp/services.rdb -c vnd.openoffice.pymodule:pythonscript -l
com.sun.star.loader.Python
vnd.openoffice.pymodule:pythonscript
register component 'vnd.openoffice.pymodule:pythonscript' in registry
'/tmp/services.rdb' succesful!

So, would it be possible to again get access to your box, to see what the actual
problem is?

Thanks in advance

  Kay

I finally managed to get a stacktrace (thanks to Pavel):

(gdb) info threads
  3 process 10479  0x00002b4f6d214fc9 in do_lookup_x () from
/lib64/ld-linux-x86-64.so.2
* 2 process 10500  0x00002b4f6da64a5f in pthread_cond_timedwait@@GLIBC_2.3.2 ()
from /lib64/tls/libpthread.so.0
  1 process 10501  0x0000000000409ce3 in com::sun::star::uno::cpp_release ()
(gdb) thread 3
[Switching to thread 3 (process 10479)]#0  0x00002b4f6d214fc9 in do_lookup_x ()
from /lib64/ld-linux-x86-64.so.2
(gdb) bt
#0  0x00002b4f6d214fc9 in do_lookup_x () from /lib64/ld-linux-x86-64.so.2
#1  0x00002b4f6d215372 in _dl_lookup_symbol_x () from /lib64/ld-linux-x86-64.so.2
#2  0x00002b4f6d2181f1 in fixup () from /lib64/ld-linux-x86-64.so.2
#3  0x00002b4f6d217f32 in _dl_runtime_resolve () from /lib64/ld-linux-x86-64.so.2
#4  0x00002b4f6d63c506 in uno_EnvDcp_getPurpose ()
   from
/data/oo/BuildDir/ooo_SRC680_m215_src/solver/680/unxlngx6.pro/lib/libuno_cppu.so.3
#5  0x00002b4f6d63c541 in uno_EnvDcp_getPurpose ()
   from
/data/oo/BuildDir/ooo_SRC680_m215_src/solver/680/unxlngx6.pro/lib/libuno_cppu.so.3
#6  0x00002b4f6d61f522 in ?? () from
/data/oo/BuildDir/ooo_SRC680_m215_src/solver/680/unxlngx6.pro/lib/libuno_cppu.so.3
#7  0x00007fffffb389f0 in ?? ()
#8  0x00002b4f6d642e81 in ?? () from
/data/oo/BuildDir/ooo_SRC680_m215_src/solver/680/unxlngx6.pro/lib/libuno_cppu.so.3
#9  0x0000000000000000 in ?? ()
#10 0x00002b4f6d218c28 in _dl_fini () from /lib64/ld-linux-x86-64.so.2

(gdb) thread 2
[Switching to thread 2 (process 10500)]#0  0x00002b4f6da64a5f in
pthread_cond_timedwait@@GLIBC_2.3.2 ()
   from /lib64/tls/libpthread.so.0
(gdb) bt
#0  0x00002b4f6da64a5f in pthread_cond_timedwait@@GLIBC_2.3.2 () from
/lib64/tls/libpthread.so.0
#1  0x00002b4f6d360d4f in rtl_cache_create ()
   from
/data/oo/BuildDir/ooo_SRC680_m215_src/solver/680/unxlngx6.pro/lib/libuno_sal.so.3
#2  0x00002b4f6da61fa5 in start_thread () from /lib64/tls/libpthread.so.0
#3  0x00002b4f6e269cb2 in clone () from /lib64/tls/libc.so.6

(gdb) thread 1
[Switching to thread 1 (process 10501)]#0  0x0000000000409ce3 in
com::sun::star::uno::cpp_release ()
(gdb) bt
#0  0x0000000000409ce3 in com::sun::star::uno::cpp_release ()
#1  0x00002b4f6d62a1cb in uno_type_constructData ()
   from
/data/oo/BuildDir/ooo_SRC680_m215_src/solver/680/unxlngx6.pro/lib/libuno_cppu.so.3
#2  0x00002b4f6d631e81 in uno_any_destruct ()
   from
/data/oo/BuildDir/ooo_SRC680_m215_src/solver/680/unxlngx6.pro/lib/libuno_cppu.so.3
#3  0x00002aaaac1219aa in pyuno::PyUNO_del ()
   from
/data/oo/BuildDir/ooo_SRC680_m215_src/solver/680/unxlngx6.pro/lib/libpyuno.so
#4  0x00002aaaac29822f in PyDict_Next ()
   from
/data/oo/BuildDir/ooo_SRC680_m215_src/solver/680/unxlngx6.pro/lib/libpython2.3.so.1.0
#5  0x00002aaaac27b903 in PyMethod_Fini ()
   from
/data/oo/BuildDir/ooo_SRC680_m215_src/solver/680/unxlngx6.pro/lib/libpython2.3.so.1.0
#6  0x00002aaaac13472a in pyuno::GCThread::run ()
   from
/data/oo/BuildDir/ooo_SRC680_m215_src/solver/680/unxlngx6.pro/lib/libpyuno.so
#7  0x00002aaaac134a1a in threadFunc () from
/data/oo/BuildDir/ooo_SRC680_m215_src/solver/680/unxlngx6.pro/lib/libpyuno.so
#8  0x00002b4f6d352ffd in osl_yieldThread ()
   from
/data/oo/BuildDir/ooo_SRC680_m215_src/solver/680/unxlngx6.pro/lib/libuno_sal.so.3
#9  0x00002b4f6da61fa5 in start_thread () from /lib64/tls/libpthread.so.0
#10 0x00002b4f6e269cb2 in clone () from /lib64/tls/libc.so.6
#11 0x0000000000000000 in ?? ()

Obviously this is PyUno related, so it shouldn't be experienced in SO builds, as
SO does not bring PyUno.

@kr:  "it shouldn't be experienced in SO builds" --- Fits into the picture, as I
experienced it when doing OOo builds, not SO builds.  Sorry I did not mention
that earlier...

The stacks also show, that some GC thread is used to asynchronously destroy some
objects. Especially the construct and comments regarding
"g_destructorsOfStaticObjectsHaveBeenCalled" (see
pyuno/source/module/pyuno_gc.cxx) seem to be fragile, especially as it looks
like that something is going wrong while terminating ...

Added JBU to CC:

->Joerg, could you give some supporting comments? Thanks, Kay

OK, it seems I finally found a fix for this. 
Actually
 i78284 (this issue), i78300 and i77991
are all the same, and are all related to the fact, that C++ d'tors have a
relationship to "atexit" (see
http://wiki.services.openoffice.org/wiki/Uno/Cpp/Tutorials/Global_References for
details), leading to a wrong order of destruction.

The fix is, to disable this feature!

kr: you rock!

Guys, sorry for disappointing you, the fix is not yet ready (but close to :-). I
think I now understand why this does not happen in the Sun build env, even when
building Python etc.

Looking at the switches, our local gcc has been compiled to support:
> gcc -v
Reading specs from
/so/env/gcc_3.4.1_p_linux_libc2.24/lib/gcc/i686-pc-linux-gnu/3.4.1/specs
Configured with: ./configure --prefix=/so/env/gcc_3.4.1_p_linux_libc2.24
--with-gnu-as --with-as=/so/env/gcc_3.4.1_p_linux_libc2.24/bin/as --with-gnu-ld
--with-ld=/so/env/gcc_3.4.1_p_linux_libc2.24/bin/ld --enable-languages=c,c++
Thread model: posix
gcc version 3.4.1

And a standard Ubuntu one:
> gcc -v
Using built-in specs.
Target: i486-linux-gnu
Configured with: ../src/configure -v
--enable-languages=c,c++,fortran,objc,obj-c++,treelang --prefix=/usr
--enable-shared --with-system-zlib --libexecdir=/usr/lib
--without-included-gettext --enable-threads=posix --enable-nls
--program-suffix=-4.1 --enable-__cxa_atexit --enable-clocale=gnu
--enable-libstdcxx-debug --enable-mpfr --enable-checking=release i486-linux-gnu
Thread model: posix
gcc version 4.1.2 (Ubuntu 4.1.2-0ubuntu4)

The local one is missing "--enable-__cxa_atexit", which is (at least that is
what the documentation says), required for strict C++ compliance. 

Doing some tests (which I am going to put on the wiki), I see a difference in
destruction order, comparing our local gcc with a plain Ubuntu one. Basically
leading to the effect, that using the local one the crashes are _not_
reproduceable. 

Certainly the fix is not disabling "__cxa_atexit" ... ;-)  By the way, a similar
/ close problem is known as "The Dead Reference Problem" (see Alexandrescu,
"Modern C++ Design").

Still, I see crashes with the Sun-local gcc 3.4.1 (and --enable-__cxa_atexit is
probably on by default, given that libs built with the Sun-local gcc 3.4.1 do
have dependencies on the __cxa_atexit symbol).

->SB: I can not confirm your observations, building with local gcc and with
"-fuse-cxa-atexit" gives 
> nm libbla.so | grep -i exit
         U __cxa_atexit@@GLIBC_2.1.3
>

building without "-fuse-cxa-atexit" gives
> nm libbla.so | grep -i exit
>

However, I am digging further and sure will find a satisfactory solution soon
... :-)

Hi,

for some (certainly discussable,let me know if you are interested) reason, the
pyuno bridge needs a separate thread to release python objects (and thus
potentially uno objects as it is the case in the callstack given above).

This can lead to crashes at process termination, because the race between
"regcomp releases all loader/factory objects and terminates main()" and
"pyuno-gc-thread release call" is not solved. 

The "static destructor guard" worked for my earlier problems, but it can't avoid
the core race, so when it hits you now, it might be, that you cant find a
compiler switch, which will make it work. 

The urp remote bridge had (and may have it still, dont know) the same problem
(see urp_environment.cxx and g_bStaticDestructorsCalled).

The crash can be avoided
1) (easy and dirty) terminating regcomp with _exit()
2) introduce a process termination synchronization API eg. in sal, which can
cleanly solve the races, here changes in regcomp (and all other uno executables
which currently dare to terminate with exit()), sal and pyuno are necessary. But
as everyone, who uses a thread as implementation detail in the uno world has the
same problem, it might be the way to go.

Bye,

Joerg

*** Issue 78300 has been marked as a duplicate of this issue. ***

*** Issue 77991 has been marked as a duplicate of this issue. ***

Finally fixed ...

kr: unomacli64?

Can I delete builddir on test machine?

->Pavel, sorry for not informing you ... you certainly can delete my ssh account
and the build dir, I think I understood the issue and could fix it independently. 

By the way, one of the reasons I couldn't reproduce it here is a differently
configured gcc in the Hamburg build env. (see my earlier comments), I am going
to write an issue for that ...

Yes, with unomacli64, it works perfectly. Thanks!

Created attachment 46196 [details]
Use NOOPTFILES instead of adding CFLAGSNOOPT

jkim: yes, that solution is much better.

Kay?

Can you verified the attached patch as well?  We should not add CFLAGSNOOPT
after existing optimization flags.  Also, we don't want to turn off optimization
for anything else.  Any way, I am still seeing the problem on FreeBSD/amd64:

> sizeof(AlignSize_Impl) = 16; __alignof__ (AlignSize_Impl) = 8
> sizeof(M) = 8; __alignof__ (M) = 4
> sizeof(N) = 12; __alignof__ (N) = 4
> sizeof(N2) = 12; __alignof__ (N2) = 4
> sizeof(O) = 24; __alignof__ (O) = 8
> sizeof(D) = 8; __alignof__ (D) = 4
> sizeof(C1) = 2; __alignof__ (C1) = 2
> sizeof(C2) = 8; __alignof__ (C2) = 4
> sizeof(C3) = 24; __alignof__ (C3) = 8
> sizeof(C4) = 40; __alignof__ (C4) = 8
> sizeof(C5) = 56; __alignof__ (C5) = 8
> sizeof(C6) = 72; __alignof__ (C6) = 8
> sizeof(O2) = 32; __alignof__ (O2) = 8
> sizeof(Char3) = 3; __alignof__ (Char3) = 1
> sizeof(P) = 24; __alignof__ (P) = 8
> sizeof(second) = 4; __alignof__ (second) = 4
Thread:      1 :component
path=file:///usr/ports/editors/openoffice.org-2-devel/work/SRC680_m216/solver/680/unxfbsdx.pro/lib/servicemgr.uno.so

=> no CPLD_ACCESSPATH set.
loadSharedLibComponentFactory envDcp: gcc3          implName:
p.stoc.ORegistryServiceManager  libName: servicemgr.uno.
Thread:      1 :> inserting new mapping: ;gcc3[8005dd008];gcc3[8005dd008]
Thread:      1 :> revoking mapping ;gcc3[8005dd008];gcc3[8005dd008]
Error: File
/usr/ports/editors/openoffice.org-2-devel/work/SRC680_m216/cppu/source/typelib/static_types.cxx,
Line 568
Thread:      1 :
### type cannot be completed: com.sun.star.container.XElementAccess
Error: File
/usr/ports/editors/openoffice.org-2-devel/work/SRC680_m216/cppu/source/typelib/typelib.cxx,
Line 1204
Segmentation fault (core dumped)

GDB backtrace:
#0  0x0000000801df4eca in typelib_typedescription_register () from
/usr/ports/editors/openoffice.org-2-devel/work/SRC680_m216/solver/680/unxfbsdx.pro/lib/libuno_cppu.so.3
#1  0x0000000801c42097 in com::sun::star::container::cppu_detail_getUnoType ()
from
/usr/ports/editors/openoffice.org-2-devel/work/SRC680_m216/solver/680/unxfbsdx.pro/lib/libuno_cppuhelpergcc3.so.3
#2  0x0000000801c422ce in
cppu::UnoType<com::sun::star::container::XEnumerationAccess>::get ()
   from
/usr/ports/editors/openoffice.org-2-devel/work/SRC680_m216/solver/680/unxfbsdx.pro/lib/libuno_cppuhelpergcc3.so.3
#3  0x0000000801c422e1 in
cppu::detail::cppu_detail_getUnoType<com::sun::star::container::XEnumerationAccess>
()
   from
/usr/ports/editors/openoffice.org-2-devel/work/SRC680_m216/solver/680/unxfbsdx.pro/lib/libuno_cppuhelpergcc3.so.3
#4  0x0000000801c422fe in
cppu::UnoType<com::sun::star::uno::Reference<com::sun::star::container::XEnumerationAccess>
>::get ()
   from
/usr/ports/editors/openoffice.org-2-devel/work/SRC680_m216/solver/680/unxfbsdx.pro/lib/libuno_cppuhelpergcc3.so.3
#5  0x0000000801c42311 in getCppuType () from
/usr/ports/editors/openoffice.org-2-devel/work/SRC680_m216/solver/680/unxfbsdx.pro/lib/libuno_cppuhelpergcc3.so.3
#6  0x0000000801c4253c in com::sun::star::container::cppu_detail_getUnoType ()
from
/usr/ports/editors/openoffice.org-2-devel/work/SRC680_m216/solver/680/unxfbsdx.pro/lib/libuno_cppuhelpergcc3.so.3
#7  0x0000000801c42f5e in cppu::UnoType<com::sun::star::container::XSet>::get ()
from
/usr/ports/editors/openoffice.org-2-devel/work/SRC680_m216/solver/680/unxfbsdx.pro/lib/libuno_cppuhelpergcc3.so.3
#8  0x0000000801c42f71 in
cppu::detail::cppu_detail_getUnoType<com::sun::star::container::XSet> ()
   from
/usr/ports/editors/openoffice.org-2-devel/work/SRC680_m216/solver/680/unxfbsdx.pro/lib/libuno_cppuhelpergcc3.so.3
#9  0x0000000801c42f8e in
cppu::UnoType<com::sun::star::uno::Reference<com::sun::star::container::XSet>
>::get ()
   from
/usr/ports/editors/openoffice.org-2-devel/work/SRC680_m216/solver/680/unxfbsdx.pro/lib/libuno_cppuhelpergcc3.so.3
#10 0x0000000801c42fa1 in getCppuType () from
/usr/ports/editors/openoffice.org-2-devel/work/SRC680_m216/solver/680/unxfbsdx.pro/lib/libuno_cppuhelpergcc3.so.3
#11 0x0000000801c42fc6 in com::sun::star::container::XSet::static_type () from
/usr/ports/editors/openoffice.org-2-devel/work/SRC680_m216/solver/680/unxfbsdx.pro/lib/libuno_cppuhelpergcc3.so.3
#12 0x0000000801c43a86 in
com::sun::star::uno::Reference<com::sun::star::container::XSet>::iquery ()
   from
/usr/ports/editors/openoffice.org-2-devel/work/SRC680_m216/solver/680/unxfbsdx.pro/lib/libuno_cppuhelpergcc3.so.3
#13 0x0000000801c43acd in Reference () from
/usr/ports/editors/openoffice.org-2-devel/work/SRC680_m216/solver/680/unxfbsdx.pro/lib/libuno_cppuhelpergcc3.so.3
#14 0x0000000801c5096d in cppu::addFactories () from
/usr/ports/editors/openoffice.org-2-devel/work/SRC680_m216/solver/680/unxfbsdx.pro/lib/libuno_cppuhelpergcc3.so.3
#15 0x0000000801c39c5a in cppu::bootstrapInitialSF () from
/usr/ports/editors/openoffice.org-2-devel/work/SRC680_m216/solver/680/unxfbsdx.pro/lib/libuno_cppuhelpergcc3.so.3
#16 0x0000000801c5101b in defaultBootstrap_InitialComponentContext () from
/usr/ports/editors/openoffice.org-2-devel/work/SRC680_m216/solver/680/unxfbsdx.pro/lib/libuno_cppuhelpergcc3.so.3
#17 0x0000000801c51c2d in cppu::defaultBootstrap_InitialComponentContext () from
/usr/ports/editors/openoffice.org-2-devel/work/SRC680_m216/solver/680/unxfbsdx.pro/lib/libuno_cppuhelpergcc3.so.3
#18 0x00000000004322aa in desktop::Desktop::CreateApplicationServiceManager ()
#19 0x000000000041aa2b in desktop::Desktop::Init ()
#20 0x00000008007509b7 in InitVCL () from
/usr/ports/editors/openoffice.org-2-devel/work/SRC680_m216/solver/680/unxfbsdx.pro/lib/libvcl680fx.so
#21 0x0000000800750c1a in ImplSVMain () from
/usr/ports/editors/openoffice.org-2-devel/work/SRC680_m216/solver/680/unxfbsdx.pro/lib/libvcl680fx.so
#22 0x0000000800750e05 in SVMain () from
/usr/ports/editors/openoffice.org-2-devel/work/SRC680_m216/solver/680/unxfbsdx.pro/lib/libvcl680fx.so
#23 0x0000000000418d4f in main ()

I forgot to add environment detail.  It is FreeBSD/amd64 -CURRENT and GCC 4.2. 
I think -fuse-cxa-atexit is on by default.

reopening.

No longer random packaging failures, but OOo crashes immediatelly on start:

oo@amd64:~/m217/program> ./soffice


Fatal exception: Signal 11
Stack:
/data/oo/m217/program/libuno_sal.so.3[0x2b111581e2fa]
/data/oo/m217/program/libuno_sal.so.3[0x2b111581e470]
/data/oo/m217/program/libuno_sal.so.3[0x2b111581e509]
/lib64/tls/libpthread.so.0[0x2b11165692c0]
/data/oo/m217/program/libuno_cppu.so.3(typelib_typedescription_register+0x114)[0x2b11156bf6c6]
/data/oo/m217/program/libuno_cppuhelpergcc3.so.3
(_ZN3com3sun4star9container22cppu_detail_getUnoTypeEPKNS2_18XEnumerationAccessE+0x177)
[0x2b111551d537]
/data/oo/m217/program/libuno_cppuhelpergcc3.so.3
(_ZN3com3sun4star9container22cppu_detail_getUnoTypeEPKNS2_4XSetE+0xcf)[0x2b111551da3f]
/data/oo/m217/program/libuno_cppuhelpergcc3.so.3
(_ZN4cppu12addFactoriesEPKPKcRKN3rtl8OUStringERKN3com3sun4star3uno9ReferenceINSA_4lang22X
MultiComponentFactoryEEERKNSC_INSA_8registry12XRegistryKeyEEE+0x2e)[0x2b111552efae]
/data/oo/m217/program/libuno_cppuhelpergcc3.so.3
(_ZN4cppu18bootstrapInitialSFERKN3rtl8OUStringE+0x1bc)[0x2b11155171cc]
/data/oo/m217/program/libuno_cppuhelpergcc3.so.3
(_ZN4cppu39_GLOBAL__N__ZN4cppu16get_this_libpathEv40defaultBootstrap_InitialComponentContextE
RKN3rtl9BootstrapE+0x79)[0x2b1115530199]
/data/oo/m217/program/libuno_cppuhelpergcc3.so.3
(_ZN4cppu40defaultBootstrap_InitialComponentContextEv+0x14)[0x2b1115530ed4]
/data/oo/m217/program/soffice.bin(_ZN7desktop7Desktop31CreateApplicationServiceManagerEv
+0x25)[0x434c75]
/data/oo/m217/program/soffice.bin(_ZN7desktop7Desktop4InitEv+0x1b)[0x41cedb]
/data/oo/m217/program/libvcl680lx.so
(_Z7InitVCLRKN3com3sun4star3uno9ReferenceINS1_4lang20XMultiServiceFactoryEEE+0x29b)
[0x2b1113f994ab]
/data/oo/m217/program/libvcl680lx.so[0x2b1113f9972f]
/data/oo/m217/program/libvcl680lx.so(_Z6SVMainv+0x25)[0x2b1113f99925]
/data/oo/m217/program/soffice.bin(main+0x3f)[0x41b75f]
/lib64/tls/libc.so.6(__libc_start_main+0xda)[0x2b1116cca5aa]
/data/oo/m217/program/soffice.bin(_ZN6Window11RequestHelpERK9HelpEvent+0x3a)[0x41b68a]
./soffice: line 236: 22306 Aborted                 "$sd_prog/$sd_binary" "$@"
oo@amd64:~/m217/program> 

(gdb) where
#0  0x00002ab722bd06c6 in typelib_typedescription_register () from /data/oo/m217/program/
libuno_cppu.so.3
#1  0x00002ab722a2e537 in com::sun::star::container::cppu_detail_getUnoType () from /data/oo/
m217/program/libuno_cppuhelpergcc3.so.3
#2  0x00002ab722a2ea3f in com::sun::star::container::cppu_detail_getUnoType () from /data/oo/
m217/program/libuno_cppuhelpergcc3.so.3
#3  0x00002ab722a3ffae in cppu::addFactories () from /data/oo/m217/program/
libuno_cppuhelpergcc3.so.3
#4  0x00002ab722a281cc in cppu::bootstrapInitialSF () from /data/oo/m217/program/
libuno_cppuhelpergcc3.so.3
#5  0x00002ab722a41199 in cppu::(anonymous 
namespace)::defaultBootstrap_InitialComponentContext () from /data/oo/m217/program/
libuno_cppuhelpergcc3.so.3
#6  0x00002ab722a41ed4 in cppu::defaultBootstrap_InitialComponentContext () from /data/oo/m217/
program/libuno_cppuhelpergcc3.so.3
#7  0x0000000000434c75 in desktop::Desktop::CreateApplicationServiceManager ()
#8  0x000000000041cedb in desktop::Desktop::Init ()
#9  0x00002ab7214aa4ab in InitVCL () from /data/oo/m217/program/libvcl680lx.so
#10 0x00002ab7214aa72f in InitVCL () from /data/oo/m217/program/libvcl680lx.so
#11 0x00002ab7214aa925 in SVMain () from /data/oo/m217/program/libvcl680lx.so
#12 0x000000000041b75f in main ()
(gdb) 


kr: the access to that machine is still valid for you.

I am fine with "NOOPTFILES" ...

I am going to check why it dies, have not seen it here though ... ;-( Seems to
be similar to what Kendy reported on IRC on Friday.

Just to keep you updated, it seems that some platforms don't use map files for
cppuhelper (despite the fact, that they are defined in the makefile), which
randomly leads to wrong resolution of "getCppuType" symbols, using the "non
comprehensive" versions. I experimentally fixed the map file for Linux x86-64,
and the soffice comes up again ...

Ah, it was addressed by issue 77975 and partially fixed in CWS cmcfixes35.  I
say partially because amd64 map file for cppuhelper seem to have some missing
symbols. :-(

Quick summary:
Since bunoexttm (SRC680_m212) on Unix (and alike) systems map files for
cppuhelper are mandatory. More or less, the reason for this is a design issue
regarding the generated "getCppuType" functions, which vary in implementation
depending on their desired usage. On Unix (ELF?) systems the different generated
"getCppuType" function resolution may compete, leading to undesired results in
case a shallow version succeeds.

This was not a problem on main stream Unix platforms, as these have valid map
files for cppuhelper. I just tweaked the "gcc3_linux_intel.map" file to
generically work with Linux x86/x86-64. I am currently unsure what the map files
for FreeBSD or Mac need to like like, a helping end would be appreciated.

->Pavel: I actually would like to set this issue to "resolved/verified" again,
and to have another issue for finally fixing this, as this is unrelated to the
packaging failures seen by you. I suggest to use i78830 for this purpose ...

Just checked in (unomacli64) some fixes for cppuhelper and Linux x86-64, the
brave may try it ...

->kr, I made a separate map file for FreeBSD/amd64 and it worked okay.  The last
patch from unomacli64 worked as well but you missed FreeBSD and MacOSX. ;-)  Can
you just rename it to gcc3_unix.map or something like that and remove OS and CPU
check altogether?  Thanks!

->kr, I am sorry that I missed your last comment. :-(  I cannot speak for MacOSX
but it works for FreeBSD/amd64.

->jkim: You mean the gcc3_linux_intel.map file works for FreeBSD? Does that
mean, that FreeBSD has the same ABI as Linux? If so, I am going to change the
makefile accordingly ... Mac OS X is what I am currently looking into.

->kr: yes, FreeBSD has the same ABI as Linux.

@kr:  Are you aware of cmc's current cppuhelper/salhelper map file cleanup
(cws_src680_cmcfixes35)?

->SB: I aware of Caolans work regarding the map files, I am going to discuss
this with him in i77975 ...

.

->Pavel, could you check this again (and put it on verified)? Thanks in advance.

Pavel, before you do, could you please commit a tiny change:

 _ZN4cppu20OPropertyArrayHelper4initEh;
 _ZN4cppu20OPropertyArrayHelperC1EPN3com3sun4star5beans8PropertyE?h;
 
_ZN4cppu20OPropertyArrayHelperC1ERKN3com3sun4star3uno8SequenceINS3_5beans8PropertyEEEh;
-_ZN4cppu20OPropertyArrayHelperC2EPN3com3sun4star5beans8PropertyElh;
+_ZN4cppu20OPropertyArrayHelperC2EPN3com3sun4star5beans8PropertyE?h;
 
_ZN4cppu20OPropertyArrayHelperC2ERKN3com3sun4star3uno8SequenceINS3_5beans8PropertyEEEh;
 
_ZN4cppu20WeakImplHelper_queryERKN3com3sun4star3uno4TypeEPNS_10class_dataEPvPNS_11OWeakObjectE;
 _ZN4cppu20createNestedRegistryERKN3rtl8OUStringE;

->Kendy: Applied and committed ... ;-)

Verified in unomacli64.

Everything works as expected.

Thanks!

closing ...