You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@activemq.apache.org by "Helen Huang (Issue Comment Edited) (JIRA)" <ji...@apache.org> on 2012/03/15 16:31:41 UTC

[jira] [Issue Comment Edited] (AMQCPP-388) AprPool::getAprPool() returns NULL, causing access violation and application crash

    [ https://issues.apache.org/jira/browse/AMQCPP-388?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13230234#comment-13230234 ] 

Helen Huang edited comment on AMQCPP-388 at 3/15/12 3:30 PM:
-------------------------------------------------------------

I think adding a call to synchronize the access to "this->config->activeSessions"  in ActiveMQConnection.cpp::cleanup() might help. (See details below)

I know "this->config->activeSessions"  has a mutex to synchronize the addition and removal of a session from that array. But a thread can still use a iterator to access/despose the session directly.


void ActiveMQConnection::cleanup() {

   try{

        // Get the complete list of active sessions.

//My code
this->config->activeSessions->mutex.lock();

        std::auto_ptr< Iterator<ActiveMQSession*> > iter( this->config->activeSessions.iterator() );

        // Dispose of all the Session resources we know are still open.
        while( iter->hasNext() ) {
            ActiveMQSession* session = iter->next();
            try{
                session->dispose();
            } catch( cms::CMSException& ex ){
                /* Absorb */
            }
        }

//My code
this->config->activeSessions->mutex.unlock();


        if( this->config->isConnectionInfoSentToBroker ) {
            if( !transportFailed.get() && !closing.get() ) {
                this->syncRequest( this->config->connectionInfo->createRemoveCommand() );
            }
            this->config->isConnectionInfoSentToBroker = false;
        }

        if( this->config->userSpecifiedClientID ) {
            this->config->connectionInfo->setClientId("");
            this->config->userSpecifiedClientID = false;
        }

        this->config->clientIDSet = false;
        this->started.set( false );
    }
    AMQ_CATCH_ALL_THROW_CMSEXCEPTION()
}

                
      was (Author: hhuang):
    I think adding a mutex to synchronize the access to "this->config->activeSessions"  in ActiveMQConnection.cpp could help:

void ActiveMQConnection::cleanup() {

    try{

        // Get the complete list of active sessions.
        std::auto_ptr< Iterator<ActiveMQSession*> > iter( this->config->activeSessions.iterator() );

        // Dispose of all the Session resources we know are still open.
        while( iter->hasNext() ) {
            ActiveMQSession* session = iter->next();
            try{
                session->dispose();
            } catch( cms::CMSException& ex ){
                /* Absorb */
            }
        }

        if( this->config->isConnectionInfoSentToBroker ) {
            if( !transportFailed.get() && !closing.get() ) {
                this->syncRequest( this->config->connectionInfo->createRemoveCommand() );
            }
            this->config->isConnectionInfoSentToBroker = false;
        }

        if( this->config->userSpecifiedClientID ) {
            this->config->connectionInfo->setClientId("");
            this->config->userSpecifiedClientID = false;
        }

        this->config->clientIDSet = false;
        this->started.set( false );
    }
    AMQ_CATCH_ALL_THROW_CMSEXCEPTION()
}
                  
> AprPool::getAprPool() returns NULL, causing access violation and application crash
> ----------------------------------------------------------------------------------
>
>                 Key: AMQCPP-388
>                 URL: https://issues.apache.org/jira/browse/AMQCPP-388
>             Project: ActiveMQ C++ Client
>          Issue Type: Bug
>          Components: Decaf
>    Affects Versions: 3.2.3
>         Environment: Windows xp service pack 3, ActiveMQ broker 5.3.1, apr 1.4.2, apr-util 1.3.9, apr iconv 1.2.1
>            Reporter: Helen Huang
>            Assignee: Timothy Bish
>            Priority: Critical
>             Fix For: 3.2.3
>
>         Attachments: BrokerMonitor.zip
>
>
> Our application that uses activemq c++ client lib crashed with the following dump:
> ----------------------------------------------------------------------------------------------------------------------
> Thread 87 - System ID 3780
> Function     Arg 1     Arg 2     Arg 3   Source 
> libapr_1!apr_pvsprintf+8     00000000     0642a188     180eeb94    
> activemq_cppu!decaf::lang::Exception::buildMessage+71     0642a188     180eeb74     180eee2c    
> activemq_cppu!decaf::lang::exceptions::RuntimeException::RuntimeException+4d     180efeec     0642a160     00000097    
> activemq_cppu!decaf::lang::ThreadProperties::runCallback+125     180eee2c     180efee0     00000001    
> msvcr80!CatchIt+5c     00000000     00000000     00000000
> LIBAPR_1!APR_PVSPRINTF+8In scotapp.dmp the assembly instruction at libapr_1!apr_pvsprintf+8 in C:\scot\dll\libapr-1.dll has caused an access violation exception (0xC0000005) when trying to read from memory location 0x0000002c on thread 87
> --------------------------------------------------------------------------------------------------------------------
> On the call stack, we saw that following function from class decaf::lang::Exception was called:
> void Exception::buildMessage( const char* format, va_list& vargs ) {
>     // Allocate buffer with a guess of it's size
>     AprPool pool;
>     // Allocate a buffer of the specified size.
>     char* buffer = apr_pvsprintf( pool.getAprPool(), format, vargs );
>     // Guessed size was enough. Assign the string.
>     message.assign( buffer, strlen( buffer ) );
> }
> The first parameter passed into apr_pvsprintf was NULL, causing the crash. Could you please take a look and see if there is any bug in the activemqcpp code that could cause the problem. Thanks!

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira