Thanks Stefan, you've been extremely helpful so far. I mitigated the second issue in my last post as well, I was doing some incorrect initialization in one of my subclasses (I believe I was forgetting to call eq::Node::configInit() in my subclass).
And of course I've come across another issue (which I actually managed to solve but I figured I should bring it up). I'm following the eqPly paradigm of having a FrameData object derive from eq::fabric::Serializable. The implementation that I have is barebones (a eq::Matrix4f + eq::Vector3f for camera position and serialize/deserialize functions for these things). The issue that I was running into is an access violation when launching my client, before it even hits main(). I believe it is during the initialization of some globals used by Fabric. I'm copy pasting the disassembly (the last line is the one that throws the EXC_BAD_ACCESS). > 0x0002dfd0 <+0000> push %ebp > 0x0002dfd1 <+0001> mov %esp,%ebp > 0x0002dfd3 <+0003> push %edi > 0x0002dfd4 <+0004> push %esi > 0x0002dfd5 <+0005> sub $0x10,%esp > 0x0002dfd8 <+0008> call 0x2dfdd > <_GLOBAL__I__ZN2eq6fabric13RenderContextC2Ev+13> > 0x0002dfdd <+0013> pop %esi > 0x0002dfde <+0014> lea 0xea33b(%esi),%eax > 0x0002dfe4 <+0020> mov %eax,(%esp) > 0x0002dfe7 <+0023> call 0xd9978 <dyld_stub__ZNSt8ios_base4InitC1Ev> > 0x0002dfec <+0028> mov 0xe617b(%esi),%edi > 0x0002dff2 <+0034> mov %edi,0x8(%esp) > 0x0002dff6 <+0038> lea -0x36d(%esi),%ecx > 0x0002dffc <+0044> mov %ecx,(%esp) > 0x0002dfff <+0047> movl $0x0,0x4(%esp) > 0x0002e007 <+0055> call 0xd9a2c <dyld_stub___cxa_atexit> > 0x0002e00c <+0060> mov 0xe61a7(%esi),%eax > 0x0002e012 <+0066> cmpb $0x0,(%eax) > 0x0002e015 <+0069> jne 0x2e063 > <_GLOBAL__I__ZN2eq6fabric13RenderContextC2Ev+147> > 0x0002e017 <+0071> movb $0x1,(%eax) > 0x0002e01a <+0074> mov 0xe615f(%esi),%eax > 0x0002e020 <+0080> movl $0xbf800000,(%eax) > 0x0002e026 <+0086> movl $0x3f800000,0x4(%eax) > 0x0002e02d <+0093> movl $0xbf800000,0x8(%eax) > 0x0002e034 <+0100> movl $0x3f800000,0xc(%eax) > 0x0002e03b <+0107> movl $0x3dcccccd,0x10(%eax) > 0x0002e042 <+0114> movl $0x42c80000,0x14(%eax) > 0x0002e049 <+0121> mov %edi,0x8(%esp) > 0x0002e04d <+0125> lea -0x37d(%esi),%ecx > 0x0002e053 <+0131> mov %ecx,(%esp) > 0x0002e056 <+0134> movl $0x0,0x4(%esp) > 0x0002e05e <+0142> call 0xd9a2c <dyld_stub___cxa_atexit> > 0x0002e063 <+0147> mov 0xe619b(%esi),%eax > 0x0002e069 <+0153> cmpb $0x0,(%eax) > 0x0002e06c <+0156> jne 0x2e0a5 > <_GLOBAL__I__ZN2eq6fabric13RenderContextC2Ev+213> > 0x0002e06e <+0158> movb $0x1,(%eax) > 0x0002e071 <+0161> pxor %xmm0,%xmm0 > 0x0002e075 <+0165> mov 0xe61ab(%esi),%eax > 0x0002e07b <+0171> movaps %xmm0,0x30(%eax) > The issue stemmed from me using the eq::vector3f::ZERO in ANY place in my code (for instance as an argument to a ctor of eq::vector3f or by doing an assignment operation to an eq::vector3f) without actually having a normal eq::vector3f() constructor invoked before. I THINK that this is because eq::vector3f::ZERO is defined as a static and, without invoking any other eq::vector3f functions before that, the respective part the library doesn't get loaded or something, thus referring to eq::vector3f::ZERO results in everything blowing up.... This is a wild guess but I wanted to confirm... -- View this message in context: http://software.1713.n2.nabble.com/Access-violation-in-co-Connection-recvSync-tp7073993p7076039.html Sent from the Equalizer - Parallel Rendering mailing list archive at Nabble.com. _______________________________________________ eq-dev mailing list [email protected] http://www.equalizergraphics.com/cgi-bin/mailman/listinfo/eq-dev http://www.equalizergraphics.com
