[
https://issues.apache.org/activemq/browse/AMQCPP-122?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_39382
]
Albert Strasheim commented on AMQCPP-122:
-----------------------------------------
Much better. I ran my pyactivemq tests that caused the crash quite reliably,
and it seems rock solid now.
As an added bonus, it seems like the memory leak I reported in AMQCPP-121 has
also been resolved.
Unfortunately, I've encountered another crash with SocketInputStream at the top
of the stack in one of the threads, so there might still be some problems
lurking. This one is much harder to reproduce (it happens when a Session is
shutting down), so it might take me a day or two to get a decent test case for
it. I'll file a separate issue for this once I have it figured out a bit more.
I have a question at this point. I see SocketInputStream is synchronizable.
When the program runs, the main thread can call IOTransport::close() which
calls inputStream->close(). Meanwhile another thread is executing
IOTransport::run() which calls reader->readCommand() which eventually calls
into this same inputStream's read. Does either thread ever take a lock while
doing these operations (close or read)? If not, does the current code work
because the inputStream's close is simple enough to happen atomically? What
would happen if close() were changed in future to do more than set a flag?
> Crash on Windows when rapidly creating and destroying connections
> -----------------------------------------------------------------
>
> Key: AMQCPP-122
> URL: https://issues.apache.org/activemq/browse/AMQCPP-122
> Project: ActiveMQ C++ Client
> Issue Type: Bug
> Affects Versions: 2.1
> Reporter: Albert Strasheim
> Assignee: Timothy Bish
> Fix For: 2.1
>
> Attachments: IOTransportConcurrentv1.patch
>
>
> Me again. :)
> The following program crashes within a few seconds on my Windows XP machine.
> This machine has a Core 2 Duo processor (i. e. 2 cores).
> On my Pentium 4 + Hyperthreading Linux machine is only dies after about a
> minute with:
> terminate called after throwing an instance of
> 'activemq::exceptions::ActiveMQException'
> what(): Cannot assign requested address
> Aborted
> However, this is to be expected, since the program causes thousands of
> sockets to be created. This doesn't seem to be the reason it crashes on
> Windows though.
> The code:
> {code:none}
> #include <activemq/core/ActiveMQConnectionFactory.h>
> #include <cms/Connection.h>
> #include <cms/Session.h>
> #include <cms/MessageProducer.h>
> #include <cms/DeliveryMode.h>
> int main(int argc, char* argv[]) {
> activemq::core::ActiveMQConnectionFactory
> connectionFactory("tcp://localhost:61613?wireFormat=stomp");
> while(true)
> {
> cms::Connection* connection = connectionFactory.createConnection();
> cms::Session* session =
> connection->createSession(cms::Session::AUTO_ACKNOWLEDGE);
> cms::Topic* topic = session->createTopic("topic");
> cms::MessageProducer* producer = session->createProducer(topic);
> delete producer;
> delete topic;
> delete session;
> delete connection;
> }
> return 0;
> }
> {code}
> The stack trace when it crashes:
> > activemq-cppd.dll!activemq::io::BufferedInputStream::read() Line 79 +
> > 0x12 bytes C++
>
> activemq-cppd.dll!activemq::connector::stomp::StompCommandReader::readStompHeaderLine()
> Line 194 + 0x19 bytes C++
>
> activemq-cppd.dll!activemq::connector::stomp::StompCommandReader::readStompCommandHeader(activemq::connector::stomp::StompFrame
> & frame={...}) Line 101 C++
>
> activemq-cppd.dll!activemq::connector::stomp::StompCommandReader::readCommand()
> Line 59 C++
> activemq-cppd.dll!activemq::transport::IOTransport::run() Line 166 +
> 0x19 bytes C++
> activemq-cppd.dll!activemq::concurrent::Thread::runCallback(void *
> param=0x003ad328) Line 152 + 0x13 bytes C++
> msvcr80d.dll!_callthreadstartex() Line 348 + 0xf bytes C
> msvcr80d.dll!_threadstartex(void * ptd=0x003adac0) Line 331 C
> kernel32.dll!7c80b683()
> [Frames below may be incorrect and/or missing, no symbols loaded for
> kernel32.dll]
> The line in BufferedInputStream::read is:
> char returnValue = buffer[head++];
> There is a local variable called bufferSize with a value of 1024. However,
> the value of head is usually much larger than bufferSize (like more than
> 10000).
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
