Hi Chuck, I haven't seen that exact problem, but for me, 9 times out of 10 mysterious problems between debug and release versions boiled down to build issues.
While the following rules of thumb can probably be relaxed in some situations, I tried to always make sure: Never mix debug and release DLLs created by the C++ compiler. All debug or all release. (But OK to mix debug C# with release C++) Make sure all C++ DLLs are compiled and linked the same. That means examining the CMake builds of the common, client and messaging libraries and using the defines, directives, and library paths as the "master" switches. Then make sure your VS C++/CLI DLLs use the identical compile and link switches. Note that this also means that your Boost libs need to be compiled the same too. And since the switches or DLL names do change from debug to release, it means careful squinting at two full sets of build logs to be sure you didn't copy/paste the wrong stuff from debug to release directives in your Visual Studio project file. Very tedious but very important. Also be sure to verify that the expected DLLs were pulled in at run time. The other common culprit was due to MP bugs in my own code, but I would be far more likely to see those on tear down (finalizers) than on startup. Cliff On Tue, Sep 21, 2010 at 9:00 AM, Chuck Rolke <[email protected]> wrote: > Hi, > > I'm working with the qpid cpp messaging dotnet client. A quick review: user > programs are in a .NET managed language, say C#. They refer to an Interop > DLL that connects them to the unmanaged qpid messaging layer built by > qpid/cpp. > > Running under debug things are fine. However, when I switch to Release or > RelWithDebInfo, the qpid messaging DLL functions crash in the function > prologue while it is trying to install it's exception handler. I've > reproduced that failing call chain below. It acts like the FS:[0] chain is > read-only. > > From reading John Robbins I suspect that default exception handling being > synchronous in Debug and asynchronous in Release may be an issue but I can't > pinpoint it. All the qpid messaging dlls are linked the same (/EHsc, > Multi-threaded DLL) for Debug and Release. In Debug mode one can step > through writing to FS:[0] just fine. > > I'd appreciate some discussion. > > Regards, > Chuck > > C# code > ======= > > connection = new Connection(broker); > > C++ Binding DLL > =============== > > Connection::Connection(System::String ^ url) : > connectionp(new > ::qpid::messaging::Connection(QpidMarshal::ToNative(url))) > { > } > > Qpid Messaging DLL > ================== > > qpid::messaging::Connection::Connection: > > 6264E580 push 0FFFFFFFFh > 6264E582 push 626841EBh > 6264E587 mov eax,dword ptr fs:[00000000h] > 6264E58D push eax > 6264E58E push ecx > 6264E58F push esi > 6264E590 mov eax,dword ptr [___security_cookie (626A92D0h)] > 6264E595 xor eax,esp > 6264E597 push eax > 6264E598 lea eax,[esp+0Ch] > 6264E59C mov dword ptr fs:[00000000h],eax <--- fails here > 6264E5A2 mov esi,ecx > 6264E5A4 push 1F8h > 6264E5A9 mov dword ptr [esi],0 > 6264E5AF call operator new (62682202h) > > --------------------------------------------------------------------- > Apache Qpid - AMQP Messaging Implementation > Project: http://qpid.apache.org > Use/Interact: mailto:[email protected] > >
