GCC segmentation fault, static initalization problem?

[pHySiQuE]

I've been working on this all day.

I build my game engine as a Linux shared object (.so) file. Newton is part of this shared object. Then I call dlopen() from my main program, to load the engine.

Sometimes when I call dlopen I get the following error:

segmentation fault (core dumped)

I debugged the program with Code::Blocks (GDB) and got this stack trace:

stack.jpg (231.89 KiB) Viewed 8493 times

It looks like maybe a static object is being initialized when dlopen() is called, and the order is not guaranteed? Or something like that?
http://gcc.gnu.org/ml/gcc-help/1999-10/msg00496.html

Can you comment on this? Thank you.

[pHySiQuE]

It looks like it's occuring at this line in dgMatrix.h:

Code: Select all

void PolarDecomposition (dgMatrix& transformMatrix, dgVector& scale, dgMatrix& stretchAxis, const dgMatrix& initialStretchAxis = dgGetIdentityMatrix()) const;

[pHySiQuE]

Here's some more information, It's occuring in a constructor in the static zeroMatrix constructor:

LD_LIBRARY_PATH=.:
Command-line: /usr/bin/gdb -nx -fullname -quiet -args ../../../Editor/test.debug
Working dir : /home/josh/Applications/Leadwerks/Engine/Projects/Linux/
Reading symbols from /home/josh/Applications/Leadwerks/Editor/test.debug...(no debugging symbols found)...done.
(gdb)
> set prompt >>>>>>cb_gdb:
>>>>>>cb_gdb:
> show version
GNU gdb (Ubuntu/Linaro 7.4-2012.04-0ubuntu2.1) 7.4-2012.04
Copyright (C) 2012 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law. Type "show copying"
and "show warranty" for details.
This GDB was configured as "x86_64-linux-gnu".
For bug reporting instructions, please see:
<http://bugs.launchpad.net/gdb-linaro/>.
>>>>>>cb_gdb:
> set confirm off
>>>>>>cb_gdb:
> set width 0
>>>>>>cb_gdb:
> set height 0
>>>>>>cb_gdb:
> set breakpoint pending on
>>>>>>cb_gdb:
> set print asm-demangle on
>>>>>>cb_gdb:
> set unwindonsignal on
>>>>>>cb_gdb:
> set disassembly-flavor intel
>>>>>>cb_gdb:
> catch throw
Function "__cxa_throw" not defined.
Catchpoint 1 (throw)
>>>>>>cb_gdb:
> source /usr/share/codeblocks/scripts/stl-views-1.0.3.gdb
>>>>>>cb_gdb:
> cd ../../../Editor
>>>>>>cb_gdb:
> directory ../../Source
>>>>>>cb_gdb:
> directory /home/josh/Applications/Leadwerks/Engine/Projects/Linux/
>>>>>>cb_gdb:
> directory /home/josh/Applications/Leadwerks/
>>>>>>cb_gdb:
> run
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/lib/x86_64-linux-gnu/libthread_db.so.1".
Loading library "/home/josh/Applications/Leadwerks/Editor/Leadwerks.debug.so".
Program received signal SIGSEGV, Segmentation fault.
0xf764ac18 in dgVector::dgVector (this=0xffffd324, a=0) at /home/josh/Applications/Leadwerks/Engine/Source/Libraries/NewtonDynamics/coreLibrary_300/source/core/dgVector.h:610
/home/josh/Applications/Leadwerks/Engine/Source/Libraries/NewtonDynamics/coreLibrary_300/source/core/dgVector.h:610:16589:beg:0xf764ac18
>>>>>>cb_gdb:
> info locals
No locals.
>>>>>>cb_gdb:
> info args
this = 0xffffd324
a = 0
>>>>>>cb_gdb:
> bt 30
#0 0xf764ac18 in dgVector::dgVector (this=0xffffd324, a=0) at /home/josh/Applications/Leadwerks/Engine/Source/Libraries/NewtonDynamics/coreLibrary_300/source/core/dgVector.h:610
#1 0xf7667d23 in __static_initialization_and_destruction_0 (__initialize_p=1, __priority=65535) at /home/josh/Applications/Leadwerks/Engine/Source/Libraries/NewtonDynamics/coreLibrary_300/source/core/dgMatrix.cpp:39
#2 0xf7667e98 in _GLOBAL__sub_I_dgMatrix.cpp(void) () at /home/josh/Applications/Leadwerks/Engine/Source/Libraries/NewtonDynamics/coreLibrary_300/source/core/dgMatrix.cpp:708
#3 0xf7feaeab in ?? () from /lib/ld-linux.so.2
#4 0xf7feaf94 in ?? () from /lib/ld-linux.so.2
#5 0xf7feefa6 in ?? () from /lib/ld-linux.so.2
#6 0xf7feaccf in ?? () from /lib/ld-linux.so.2
#7 0xf7fee7f4 in ?? () from /lib/ld-linux.so.2
#8 0xf7d79be9 in ?? () from /lib/i386-linux-gnu/libdl.so.2
#9 0xf7feaccf in ?? () from /lib/ld-linux.so.2
#10 0xf7d7a33a in ?? () from /lib/i386-linux-gnu/libdl.so.2
#11 0xf7d79c97 in dlopen () from /lib/i386-linux-gnu/libdl.so.2
#12 0x08118d66 in ?? ()
#13 0x081189b0 in ?? ()
#14 0x08116eca in ?? ()
#15 0x0804c8d8 in ?? ()
#16 0xf7a9e4d3 in __libc_start_main () from /lib/i386-linux-gnu/libc.so.6
#17 0x0804c801 in ?? ()
>>>>>>cb_gdb:
> info frame
Stack level 0, frame at 0xffffd2d4:
eip = 0xf764ac18 in dgVector::dgVector (/home/josh/Applications/Leadwerks/Engine/Source/Libraries/NewtonDynamics/coreLibrary_300/source/core/dgVector.h:610); saved eip 0xf7667d23
called by frame at 0xffffd384
source language c++.
Arglist at 0xffffd2cc, args: this=0xffffd324, a=0
Locals at 0xffffd2cc, Previous frame's sp is 0xffffd2d4
Saved registers:
ebp at 0xffffd2cc, eip at 0xffffd2d0
>>>>>>cb_gdb:
> disassemble
Dump of assembler code for function dgVector::dgVector(dgFloat32):
0xf764abfa <+0>: push ebp
0xf764abfb <+1>: mov ebp,esp
0xf764abfd <+3>: sub esp,0x18
0xf764ac00 <+6>: mov eax,DWORD PTR [ebp+0xc]
0xf764ac03 <+9>: mov DWORD PTR [ebp-0x10],eax
0xf764ac06 <+12>: mov eax,DWORD PTR [ebp-0x10]
0xf764ac09 <+15>: mov DWORD PTR [ebp-0xc],eax
0xf764ac0c <+18>: movss xmm0,DWORD PTR [ebp-0xc]
0xf764ac11 <+23>: shufps xmm0,xmm0,0x0
0xf764ac15 <+27>: mov eax,DWORD PTR [ebp+0x8]
=> 0xf764ac18 <+30>: movaps XMMWORD PTR [eax],xmm0
0xf764ac1b <+33>: leave
0xf764ac1c <+34>: ret
End of assembler dump.
>>>>>>cb_gdb:

[pHySiQuE]

It appears that all the static variables have problems at initialization. This includes the following:
dgSphere.cpp:

Code: Select all

static dgSphere identitySphere;p/code[
[xode]dgSphere::dgSphere ()
   :dgMatrix(dgGetIdentityMatrix()), m_size (dgFloat32 (0.0f), dgFloat32 (0.0f), dgFloat32 (0.0f), dgFloat32 (0.0f))
{
//   dgAssert (0);
//   planeTest = FrontTest;
}

dgMatrix.cpp:

Code: Select all

static dgMatrix zeroMatrix (dgVector (dgFloat32(0.0f)),
                     dgVector (dgFloat32(0.0f)),
                     dgVector (dgFloat32(0.0f)),
                     dgVector (dgFloat32(0.0f)));

Code: Select all

static dgMatrix identityMatrix (dgVector (dgFloat32(1.0f), dgFloat32(0.0f), dgFloat32(0.0f), dgFloat32(0.0f)),
                        dgVector (dgFloat32(0.0f), dgFloat32(1.0f), dgFloat32(0.0f), dgFloat32(0.0f)),
                        dgVector (dgFloat32(0.0f), dgFloat32(0.0f), dgFloat32(1.0f), dgFloat32(0.0f)),
                        dgVector (dgFloat32(0.0f), dgFloat32(0.0f), dgFloat32(0.0f), dgFloat32(1.0f)));

Since GetidentityMatrix() is called on a ton of header files as a default argument, I am not sure what the ramifications of this are.

[pHySiQuE]

According to this page if you put the variable declaration inside the function, it will avoid the probiem and still only get initialized once:
http://www.parashift.com/c++-faq/static ... t-use.html

Code: Select all

//static dgSphere identitySphere;

const dgSphere& GetIdentitySphere()
{
    static dgSphere identitySphere;
   return identitySphere;
}

Code: Select all

const dgMatrix& dgGetIdentityMatrix()
{
    static dgMatrix identityMatrix (dgVector (dgFloat32(1.0f), dgFloat32(0.0f), dgFloat32(0.0f), dgFloat32(0.0f)),
                        dgVector (dgFloat32(0.0f), dgFloat32(1.0f), dgFloat32(0.0f), dgFloat32(0.0f)),
                        dgVector (dgFloat32(0.0f), dgFloat32(0.0f), dgFloat32(1.0f), dgFloat32(0.0f)),
                        dgVector (dgFloat32(0.0f), dgFloat32(0.0f), dgFloat32(0.0f), dgFloat32(1.0f)));
   return identityMatrix;
}

const dgMatrix& dgGetZeroMatrix ()
{
    static dgMatrix zeroMatrix (dgVector (dgFloat32(0.0f)),
                     dgVector (dgFloat32(0.0f)),
                     dgVector (dgFloat32(0.0f)),
                     dgVector (dgFloat32(0.0f)));
   return zeroMatrix;
}

When I do this, the problem goes away and I can actually make it past the initialization phase when the library is loaded.

[Julio Jerez]

That's suggestion not really a good idea. Making global static variables local static variable solve the problem is initialization order, so many more other problem that is not worth.
termination become almost impossible some you can no re-initialize then,
some variable has to be accessible directly no via a function call.

There is nothing wrong with static variable being global static and not local static.
if you are having that kind of problem is because you must be initializing the engine formed some global variable, and the brake the rule of a C interface.
Newton core has a C interface, and in C you can no make any call to any initialization before the call to main.


The internet is full of articles like that, written by self appoint experts that only knows half true of when they are talking about.
that's probably written by a who wrote a bad program and solve with an even worse solution, and some how decide that hey I figure out for to solve C++.

using singleton, and local static variable ha the uses, but no where is a rule that all global variable has to be local static variable, that's a really bad idea.
check you code you must be animalizing the engine fore a global contractor with violate the rules of a C interface.

[Julio Jerez]

ok I made identityMarix and zero Matrix static member of matrix, I do no know what version you are using because zeroSphere is not part for the engine for a while
I still do not see how that can brig a conflict, since all of the global variable in the engine are in the same file.

there is no way that a matrix will have will be unitized, since all there component are finalized before the matrix itself according to the rule of initialization of global in C++.
and like I say this global are there fore a reason, they are use in tight loop and inline variable, they can no be assesses \via a function call with will be the case if they are made local static.

they only way you can see and utilized identity matrix, if some other library is trying to use the matrix from another global variable. but since all newton function need a pointe to the newton world,
my guess is that you are trying to initialize the world in a global variable in you code, and the will be incorrect.

sync again and see if making the variable static member of the class fix it, it is more elegant that way anyway.

[pHySiQuE]

I have updated my copy of Newton and will resume testing.

I did end up using my engine as a static library. I am not sure what was going on, but GCC seems to be more sensitive than other compilers like LLVM and Microsoft. Will let you know if anything comes up again.

[pHySiQuE]

Appears to be working okay. The problems I experienced might be limited to just shared objects.

[Julio Jerez]

Appears to be working okay. The problems I experienced might be limited to just shared objects.

what do you mean by shared objects?

[pHySiQuE]

.so files, the Linux equivalent to a DLL.

[pHySiQuE]

The problem is not gone. It seems to have something to do with the vector constructor:

Code: Select all

Starting debugger:
done
Registered new type: wxString
Registered new type: STL String
Registered new type: STL Vector
Setting breakpoints
Debugger name and version: GNU gdb (Ubuntu/Linaro 7.4-2012.04-0ubuntu2.1) 7.4-2012.04
Continuing...
Continuing...
Child process PID: 4458
At /home/josh/Leadwerks/Engine/Source/Classes/Drivers/Physics/NewtonDynamics/Classes/NewtonDynamicsShape.cpp:20
Continuing...
At /home/josh/Leadwerks/Engine/Source/Libraries/NewtonDynamics/coreLibrary_300/source/physics/dgWorld.cpp:248
At /home/josh/Leadwerks/Engine/Source/Libraries/NewtonDynamics/coreLibrary_300/source/physics/dgNarrowPhaseCollision.cpp:375
At /home/josh/Leadwerks/Engine/Source/Libraries/NewtonDynamics/coreLibrary_300/source/physics/dgContact.cpp:43
At /home/josh/Leadwerks/Engine/Source/Libraries/NewtonDynamics/coreLibrary_300/source/physics/dgContact.h:86
At /home/josh/Leadwerks/Engine/Source/Libraries/NewtonDynamics/coreLibrary_300/source/core/dgVector.h:607
Program received signal SIGSEGV, Segmentation fault.
At /home/josh/Leadwerks/Engine/Source/Libraries/NewtonDynamics/coreLibrary_300/source/core/dgVector.h:620

I tried defining the DG_SCALAR_VECTOR_CLASS macros and it made no difference, just crashed in the other constructor.

[pHySiQuE]

I realized Newton was undefining the scalar vector macro, so I modified dgtypes.h to add a new macro definition to force disabling SSE:

Code: Select all

#if defined (__USE_DOUBLE_PRECISION__) || defined (__ppc__) || defined (__ANDROID__) || defined (IOS) || defined (DG_DISABLE_SSE)
   #undef DG_SSE4_INSTRUCTIONS_SET
   #ifndef DG_SCALAR_VECTOR_CLASS
      #define DG_SCALAR_VECTOR_CLASS
   #endif
#endif

And everything works fine now.

This is only a problem with my editor, which goes through it's own compiling process and may have some weird incompatibility with GCC.

[Julio Jerez]

I see if I try to add a defien that force thet SSE scaler code.
the define you added seem fine, but SSE vecor class should also work in windows or intel Max linux system.

if the code fail on SSE then it must be because aligment.

It is important to have the vector class using sse or simd. altogh Linux does a good job, it does no reall issue many vetors operations bejoind mov for registe to register. The Vecortr class doesd Vecotr compare and prdication that use slow convetiosn to integer and only when usingthe simd spcial intrutions is when teh peek perfoemanc cna be achived.

[pHySiQuE]

Since this only runs in our editor, which doesn't do any physics simulations, it is acceptable. The static library the end user uses for games is still built with SSE for fast performance.