editors/libreoffice: can not compile, crash on, FreeBSD 9.0-CUR/amd64 - msg#00540

[Andriy Gapon]

on 31/05/2011 15:22 Olivier Smedts said the following:
> 2011/5/31 Andriy Gapon <avg at freebsd.org>:
>> on 31/05/2011 12:11 Olivier Smedts said the following:
>>> Segmentation fault: 11 (core dumped)
>>
>> That core dump should be investigated / debugged.
>> At the very least it is not clear from the messages which program crashes.
> 
> It's more clear if you read the output of the "build" command.
> 
> Well I'm not very familiar with debugging, I loaded the program and
> the core dump with gdb and asked for a backtrace, but that's all I
> know. Is there anything useful I can do ? I can also provide the core
> dump.

Speaking from general point of view, it would be nice to compile the failing
program (regcomp) and its shared libraries with debug information.  However I
don't have any advice on how to actually do it in this build environment.

[snip]
> (gdb) bt
> #0  0x000000080202c640 in ?? ()
> #1  0x0000000802461467 in stoc_impreg::insert_singletons ()
>    from /usr/ports/editors/libreoffice/work/libreoffice-build-3.3.2.2/build/libreoffice/solver/330/unxfbsdx.pro/lib/bootstrap.uno.so
> #2  0x0000000802463713 in stoc_impreg::ImplementationRegistration::doRegister ()
>    from /usr/ports/editors/libreoffice/work/libreoffice-build-3.3.2.2/build/libreoffice/solver/330/unxfbsdx.pro/lib/bootstrap.uno.so
> #3  0x0000000802464f8d in
> stoc_impreg::ImplementationRegistration::prepareRegister ()
>    from /usr/ports/editors/libreoffice/work/libreoffice-build-3.3.2.2/build/libreoffice/solver/330/unxfbsdx.pro/lib/bootstrap.uno.so
> #4  0x00000000004093ba in DoIt::operator() ()
> #5  0x000000000041aeff in
> std::for_each<__gnu_cxx::__normal_iterator<rtl::OUString*,
> std::vector<rtl::OUString, std::allocator<rtl::OUString> > >, DoIt> ()
> #6  0x0000000000409bef in main ()

>From the backtrace and some googling it seems like the problem could be - and it's
just a wild guess - because of exceptions.  In particular I've seen something like
this when libgcc_s.so used at run-time came from a compiler different than a
compiler which was used to produce an executable.  In my case it was libgcc_s.so
from base gcc at run-time versus libgcc_s.so from gcc45 at link-time.  My program
crashed on any 'throw' statement (even when an exception should have been caught).
 Again, I am not saying that this is what happens here, I am just hinting at
things to try.

P.S.  I have not debugged the actual mechanics of the crash that I have described
above.

-- 
Andriy Gapon