[openamq-dev] Subscriber memory management problems

[Martin Sustrik]

> On a related note, there is a commented line in WireAPI_Sub.cpp which
> says "delete [] buffer" ... If I uncomment this line and run the code,
> I get the following error in VC++ at run-time: "Debug Assertion
> Failed! Program: WireAPI_Sub.exe, File:
> f:\dd\vctools\crt_bld\self_x86\dbgdel.cpp, Line 52, Expression:
> _BLOCK_TYPE_IS_VALID(pHead->nBlockUse)"
The problem is obviously that you are trying to deallocate the data that 
are placed on the stack. However, I suppose that was the intent... to 
crash the client to test the stability of server, right?

>   ... The VC++ dialog box gives
> me three options: Abort, Retry, and Ignore. If I click Abort then
> first amq_server.exe itself crashes (!), giving the following message:
>
> "2008-02-25 17:53:40: (smt_socket_request.c 2490) A non-blocking
> socket operation could not be completed immediately.
> This application has requested the Runtime to terminate it in an unusual way.
> Please contact the application's support team for more information."
>   
This seems to be some strange behavior of apr_socket_recv on Windows 
platform. I'll fill the bug report.

> It is extremely distressing that my client code is
> able to crash the AMQP server. Is the OpenAMQ server designed to be
> stable no matter what the client code does? Or is it just accepted
> that a bug in a single client could stop the whole show?
>   
This is certainly not accepted. OpenAMQ broker is designed to be robust 
in the face of client failures. In fact, it runs in heavily loaded 
production environment for a long time already and no crashes were 
experienced. The problem is that our production deployments of the 
broker are on Linux and Solaris platforms. Therefore there may be few 
bugs that went unnoticed on Windows platform.

Martin