> Regardless of whether <base/logstream.h> gets included,
> and regardless of whether deal.II -r17071, -r17340 or -r17373 is used,
> compiling+linking with g++-4.0.1 (from Apple's Xcode) or g++-4.2.4
> (from MacPorts) leads to a segmentation fault.
>
> Regardless of whether <base/logstream.h> gets included,
> and regardless of whether deal.II -r17071, -r17340 or -r17373 is used,
> g++-4.3.2 (from MacPorts) happens to get it right.
>
> (I have tested all 18 combinations now.)
:-)
> To me, this looks like an order-of-initialization issue.
>
> According to "svn log" and "svn annotate" on base/source/log.cc, there
> are similar effects upon destruction of globals that have not been
> investigated deeply.
Yes, I saw something similar when linking with Trilinos under linux, but
this is addressed by the change to log.cc. Martin Kronbichler has
apparently the same problem as you on Mac which I don't see on linux,
however. He ran a program under valgrind and it showed reads to invalid
addresses at the end of the program when __cxa_finalize (a function that
runs destructors of global objects) runs which also indicates to me that
it is an ordering issue -- like something shutting down libstdc++'s memory
subsystem before running destructors of global objects that deallocate
memory, or something similarly awkward to track down.
I am rather unclear on how to address this problem. Fortunately it only
happens when the program is already done with its work... Any suggestions
are gladly accepted!
Best
Wolfgang
-------------------------------------------------------------------------
Wolfgang Bangerth email: [EMAIL PROTECTED]
www: http://www.math.tamu.edu/~bangerth/
_______________________________________________
