On 05/31/11 15:09, Andriy Gapon wrote:
on 31/05/2011 15:22 Olivier Smedts said the following:
2011/5/31 Andriy Gapon<a...@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.
As I reported eralier, LibreOffice 3.3.2 crashes on all of my FreeBSD
9.0-CURRENT/amd64 boxes compiled with CLANG. Today I compiled the OS on
one of those boxes with the optimization option "-O3" instead of the
suggested "-O2" - and voila, LibreOffice 3.3.2 as installed seems to
work again! Strange, strange ...
_______________________________________________
freebsd-ports@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"
