activemq-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Francois Godin (JIRA)" <j...@apache.org>
Subject [jira] [Updated] (AMQCPP-560) Memory used by thread is not freed when thread end
Date Wed, 11 Feb 2015 19:05:12 GMT

     [ https://issues.apache.org/jira/browse/AMQCPP-560?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]

Francois Godin updated AMQCPP-560:
----------------------------------
    Description: 
A program have one connection and may create many threads. Each of those thread can then use
that connection to generate a session. The problem happen when the session is destroyed. The
memory consumption do not go back to what it was before.

In addition, it seems that 3.8.3 on Windows (not tested on Linux with that version) is prone
to crash in that situation.

I've tried valgrind and dr memory and they did not find memory leak. This should means that
the memory is still reachable. The implication is then that when using ActiveMQ C++ on one
thread, some memory is allocated for that thread. That memory would then be kept accessible
even when the thread die/session closed/connection closed.

I've managed to build a C++11 example program. It should be noted that this program create
only one session at a time (by using join() to wait). Also, if the session is created on the
current thread (by not defining THREAD), then the memory stay stable.

It seems to also happen if we use new thread to open Connection but as creating those is slower,
it is not as easy to see.


  was:
A program have one connection and may create many threads. Each of those thread can then use
that connection to generate a session. The problem happen when the session is destroyed. The
memory consumption do not go back to what it was before.

In addition, it seems that 3.8.3 on Windows (not tested on Linux with that version) is prone
to crash in that situation.

I've tried valgrind and dr memory and they did not find memory leak. This should means that
the memory is still reachable.

I've managed to build a C++11 example program. It should be noted that this program create
only one session at a time (by using join() to wait). Also, if the session is created on the
current thread (by not defining THREAD), then the memory stay stable.


        Summary: Memory used by thread is not freed when thread end  (was: Memory consumption
increase and crash when creating sessions on multiple threads)

> Memory used by thread is not freed when thread end
> --------------------------------------------------
>
>                 Key: AMQCPP-560
>                 URL: https://issues.apache.org/jira/browse/AMQCPP-560
>             Project: ActiveMQ C++ Client
>          Issue Type: Bug
>    Affects Versions: 3.8.2, 3.8.3
>         Environment: Linux(gcc)
> Windows(Visual studio)
>            Reporter: Francois Godin
>            Assignee: Timothy Bish
>         Attachments: repro.cpp
>
>
> A program have one connection and may create many threads. Each of those thread can then
use that connection to generate a session. The problem happen when the session is destroyed.
The memory consumption do not go back to what it was before.
> In addition, it seems that 3.8.3 on Windows (not tested on Linux with that version) is
prone to crash in that situation.
> I've tried valgrind and dr memory and they did not find memory leak. This should means
that the memory is still reachable. The implication is then that when using ActiveMQ C++ on
one thread, some memory is allocated for that thread. That memory would then be kept accessible
even when the thread die/session closed/connection closed.
> I've managed to build a C++11 example program. It should be noted that this program create
only one session at a time (by using join() to wait). Also, if the session is created on the
current thread (by not defining THREAD), then the memory stay stable.
> It seems to also happen if we use new thread to open Connection but as creating those
is slower, it is not as easy to see.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

Mime
View raw message