qpid-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Cliff Jansen <cliffjan...@gmail.com>
Subject Re: Help with Windows app design
Date Tue, 21 Sep 2010 18:50:53 GMT
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.


On Tue, Sep 21, 2010 at 9:00 AM, Chuck Rolke <crolke@redhat.com> 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:dev-subscribe@qpid.apache.org

  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message