rabbitmq-c memory leak?

classic Classic list List threaded Threaded
11 messages Options
Reply | Threaded
Open this post in threaded view
|

rabbitmq-c memory leak?

Dushin Fred

I have written a simple test program using the SimpleAqmpClient library (which in turn uses the rabbitmq-c library), which seems to illustrate a memory leak, of sorts.

The program is a simple main, which pre-allocates a string message, and then calls BasicPublish on a channel in a loop, all single threaded.  Effectively:

        auto envelope = BasicMessage::Create(random_data(message_size));
        for (unsigned i = 0;  i < num_messages;  ++i)
        {
            channel->BasicPublish(exchange_name, routing_key, envelope);
        }

The problem is that the memory image of this process seems to grow without bounds.  The memory all seems to be allocated in amqp_pool_alloc (as expected), when calling wait_frame_inner -> amqp_handle_input.  The memory is not orphaned -- i.e., it seems to get cleaned up at shutdown, so it doesn't show up as a leak in a leak detector tool, such a Instruments/DTrace, or valgrind, or purify, etc.  But I don't see where the memory is every de-allocated, which will spell doom for an application that is designed to never terminate.

I am attaching a screenshot from an Instruments run, to give some context.  The code is here:


This was run against RabbitMQ 3.2.4, using rabbitmq-c 0.5.0 and SimpleAmqpClient 2.3, compiled using Clang 5.0 on OS X.9 (Mavericks).

Has anyone seen this behavior?  Am I missing something in my use of BasicPublish, that is not telling the rabbitmq-c library to free memory in the "amqp pool"?  It doesn't seem to make a difference whether I am actively pulling messages off the queue from a separate process, or even whether there is a queue bound to the exchange to which I am publishing messages.  (Not that I would expect it to)

-Fred

encl.



_______________________________________________
rabbitmq-discuss mailing list
[hidden email]
https://lists.rabbitmq.com/cgi-bin/mailman/listinfo/rabbitmq-discuss
Reply | Threaded
Open this post in threaded view
|

Re: rabbitmq-c memory leak?

alan.antonuk
SimpleAmqpClient should call MaybeReleaseBuffersOnChannel, which if it has no frames enqueued, should call amqp_maybe_release_buffers_on_channel(), which if rabbitmq-c doesn't have any frames lying around will recycle the pool associated with that channel. If this really is a bug (possible...) it would be good to know which channel(s) SimpleAmqpClient is publishing on, and which channel(s) are growing without bound (e.g., which entry in amqp_connection_state_t.pool_table).

-Alan


On Thu, Apr 3, 2014 at 5:19 PM, Dushin Fred <[hidden email]> wrote:

I have written a simple test program using the SimpleAqmpClient library (which in turn uses the rabbitmq-c library), which seems to illustrate a memory leak, of sorts.

The program is a simple main, which pre-allocates a string message, and then calls BasicPublish on a channel in a loop, all single threaded.  Effectively:

        auto envelope = BasicMessage::Create(random_data(message_size));
        for (unsigned i = 0;  i < num_messages;  ++i)
        {
            channel->BasicPublish(exchange_name, routing_key, envelope);
        }

The problem is that the memory image of this process seems to grow without bounds.  The memory all seems to be allocated in amqp_pool_alloc (as expected), when calling wait_frame_inner -> amqp_handle_input.  The memory is not orphaned -- i.e., it seems to get cleaned up at shutdown, so it doesn't show up as a leak in a leak detector tool, such a Instruments/DTrace, or valgrind, or purify, etc.  But I don't see where the memory is every de-allocated, which will spell doom for an application that is designed to never terminate.

I am attaching a screenshot from an Instruments run, to give some context.  The code is here:


This was run against RabbitMQ 3.2.4, using rabbitmq-c 0.5.0 and SimpleAmqpClient 2.3, compiled using Clang 5.0 on OS X.9 (Mavericks).

Has anyone seen this behavior?  Am I missing something in my use of BasicPublish, that is not telling the rabbitmq-c library to free memory in the "amqp pool"?  It doesn't seem to make a difference whether I am actively pulling messages off the queue from a separate process, or even whether there is a queue bound to the exchange to which I am publishing messages.  (Not that I would expect it to)

-Fred

encl.



_______________________________________________
rabbitmq-discuss mailing list
[hidden email]
https://lists.rabbitmq.com/cgi-bin/mailman/listinfo/rabbitmq-discuss



_______________________________________________
rabbitmq-discuss mailing list
[hidden email]
https://lists.rabbitmq.com/cgi-bin/mailman/listinfo/rabbitmq-discuss
Reply | Threaded
Open this post in threaded view
|

Re: rabbitmq-c memory leak?

Abhay Rajure
In reply to this post by Dushin Fred
Dushin Fred <fred@...> writes:

>
>
> I have written a simple test program using the SimpleAqmpClient library
(which in turn uses the rabbitmq-c
> library), which seems to illustrate a memory leak, of sorts.
>
> The program is a simple main, which pre-allocates a string message, and
then calls BasicPublish on a
> channel in a loop, all single threaded.  Effectively:
>
>         auto envelope = BasicMessage::Create(random_data(message_size));
>         for (unsigned i = 0;  i < num_messages;  ++i)
>         {
>             channel->BasicPublish(exchange_name, routing_key, envelope);
>         }
>
> The problem is that the memory image of this process seems to grow without
bounds.  The memory all seems to be
> allocated in amqp_pool_alloc (as expected), when calling wait_frame_inner
-> amqp_handle_input.  The
> memory is not orphaned -- i.e., it seems to get cleaned up at shutdown, so
it doesn't show up as a leak in a leak
> detector tool, such a Instruments/DTrace, or valgrind, or purify, etc.
But I don't see where the memory is
> every de-allocated, which will spell doom for an application that is
designed to never terminate.
>
> I am attaching a screenshot from an Instruments run, to give some context.
 The code is here:
>
> https://github.com/fadushin/sandbox/blob/master/cpp/rabbitmq/sender.cpp
>
> This was run against RabbitMQ 3.2.4, using rabbitmq-c 0.5.0 and
SimpleAmqpClient 2.3, compiled using
> Clang 5.0 on OS X.9 (Mavericks).
>
> Has anyone seen this behavior?  Am I missing something in my use of
BasicPublish, that is not telling the
> rabbitmq-c library to free memory in the "amqp pool"?  It doesn't seem to
make a difference whether I am
> actively pulling messages off the queue from a separate process, or even
whether there is a queue bound to
> the exchange to which I am publishing messages.  (Not that I would expect
it to)
>
> -Fred
>
> encl.
>
>
>
>
> I have written a simple test program using the SimpleAqmpClient library
(which in turn uses the rabbitmq-c
> library), which seems to illustrate a memory leak, of sorts.
>
> The program is a simple main, which pre-allocates a string message, and
then calls BasicPublish on a
> channel in a loop, all single threaded.  Effectively:
>
>         auto envelope = BasicMessage::Create(random_data(message_size));
>         for (unsigned i = 0;  i < num_messages;  ++i)
>         {
>             channel->BasicPublish(exchange_name, routing_key, envelope);
>         }
>
> The problem is that the memory image of this process seems to grow without
bounds.  The memory all seems to be
> allocated in amqp_pool_alloc (as expected), when calling wait_frame_inner
-> amqp_handle_input.  The
> memory is not orphaned -- i.e., it seems to get cleaned up at shutdown, so
it doesn't show up as a leak in a leak
> detector tool, such a Instruments/DTrace, or valgrind, or purify, etc.
But I don't see where the memory is
> every de-allocated, which will spell doom for an application that is
designed to never terminate.
>
> I am attaching a screenshot from an Instruments run, to give some context.
 The code is here:
>
> https://github.com/fadushin/sandbox/blob/master/cpp/rabbitmq/sender.cpp
>
> This was run against RabbitMQ 3.2.4, using rabbitmq-c 0.5.0 and
SimpleAmqpClient 2.3, compiled using
> Clang 5.0 on OS X.9 (Mavericks).
>
> Has anyone seen this behavior?  Am I missing something in my use of
BasicPublish, that is not telling the
> rabbitmq-c library to free memory in the "amqp pool"?  It doesn't seem to
make a difference whether I am
> actively pulling messages off the queue from a separate process, or even
whether there is a queue bound to
> the exchange to which I am publishing messages.  (Not that I would expect
it to)
>
> -Fred
>
> encl.
>
>


Seems like the issue is in SimpleAmqpClient's
ChannelImpl::MaybeReleaseBufferOnChannel() method, it fails to call
amqp_maybe_release_buffers_on_channel() because by the time it is called, it
can't find channel in m_open_channels(bug?).

Try this --

In File SimpleAmqpClient/src/ChannelImpl.cpp,
call amqp_maybe_release_buffers_on_channel() in ReturnChannel().

void ChannelImpl::ReturnChannel(amqp_chanel_t channel)
{
   +amqp_maybe_release_buffers_on_channel(m_connection, channel);
    m_free_channels.push(channel);
}

-Abhay



_______________________________________________
rabbitmq-discuss mailing list
[hidden email]
https://lists.rabbitmq.com/cgi-bin/mailman/listinfo/rabbitmq-discuss
Reply | Threaded
Open this post in threaded view
|

Re: rabbitmq-c memory leak?

Dushin Fred
That works for me, too.  Thanks, Abhay.

Alan, would you like a pull request?  Is there a timeline for folding this an the other recent fixes into master?  Anything I can do to help expedite?

-Fred

On Apr 9, 2014, at 4:54 AM, Abhay Rajure <[hidden email]> wrote:

Try this --

In File SimpleAmqpClient/src/ChannelImpl.cpp,
call amqp_maybe_release_buffers_on_channel() in ReturnChannel().

void ChannelImpl::ReturnChannel(amqp_chanel_t channel)
{
  +amqp_maybe_release_buffers_on_channel(m_connection, channel);
   m_free_channels.push(channel);
}


_______________________________________________
rabbitmq-discuss mailing list
[hidden email]
https://lists.rabbitmq.com/cgi-bin/mailman/listinfo/rabbitmq-discuss
Reply | Threaded
Open this post in threaded view
|

Re: rabbitmq-c memory leak?

alan.antonuk
What version of SimpleAmqpClient are you using? The lines surrounding your change don't seem to match what is currently in the master branch of SimpleAmqpClient. I believe behavior you're seeing was addressed a while ago (see Issue #56). Please download the master branch and build from that, you will also need rabbitmq-c v0.4.1 or newer for this to work.

FYI: the patch you are suggesting using will likely cause undefined behavior. Because of the way rabbitmq-c's memory management works, the SimpleAmqpClient cannot call amqp_maybe_release_buffers() until it no longer holds any references to frames returned from amqp_simple_wait_frame(). Once amqp_maybe_release_buffers() (or amqp_maybe_release_buffers_on_channel()) any outstanding frames are considered freed and their use will lead to undefined behavior. SimpleAmqpClient maintains a list of frames that it has seen from the broker, in ChannelImpl::MaybeReleaseBuffersOnChannel it checks to see if there are any frames that it still has a reference to before calling amqp_maybe_release_buffers()

-Alan


On Wed, Apr 9, 2014 at 3:17 PM, Dushin Fred <[hidden email]> wrote:
That works for me, too.  Thanks, Abhay.

Alan, would you like a pull request?  Is there a timeline for folding this an the other recent fixes into master?  Anything I can do to help expedite?

-Fred

On Apr 9, 2014, at 4:54 AM, Abhay Rajure <[hidden email]> wrote:

Try this --

In File SimpleAmqpClient/src/ChannelImpl.cpp,
call amqp_maybe_release_buffers_on_channel() in ReturnChannel().

void ChannelImpl::ReturnChannel(amqp_chanel_t channel)
{
  +amqp_maybe_release_buffers_on_channel(m_connection, channel);
   m_free_channels.push(channel);
}


_______________________________________________
rabbitmq-discuss mailing list
[hidden email]
https://lists.rabbitmq.com/cgi-bin/mailman/listinfo/rabbitmq-discuss



_______________________________________________
rabbitmq-discuss mailing list
[hidden email]
https://lists.rabbitmq.com/cgi-bin/mailman/listinfo/rabbitmq-discuss
Reply | Threaded
Open this post in threaded view
|

Re: rabbitmq-c memory leak?

Dushin Fred
Sorry, I should have been more clear.

The original issue I hit was from a build off the 2.3 tag (418f31f).  So the patch I applied was slightly different:

> git diff
diff --git a/src/ChannelImpl.cpp b/src/ChannelImpl.cpp
index 9749556..864502b 100644
--- a/src/ChannelImpl.cpp
+++ b/src/ChannelImpl.cpp
@@ -152,6 +152,7 @@ amqp_channel_t ChannelImpl::GetChannel()
 
 void ChannelImpl::ReturnChannel(amqp_channel_t channel)
 {
+       amqp_maybe_release_buffers_on_channel(m_connection, channel);
     m_channels.at(channel) = CS_Open;
     m_last_used_channel = channel;
 }

I fully respect that this may not be the "right" fix, but in my limited scenario (the sender.cpp program I posted off github), it does the trick.

I have done zero analysis of the right fix, but I'd be happy to crack open the code and look into it, if the root cause of the bug is not immediately evident to you.  Otherwise, if you have any thoughts, feel free to let me know.

And of course I would prefer (as I suspect many would) that the fix go into master, as this bug seems to effectively render the C++ client library unsuitable for production, and I would prefer not to maintain a fix that is not endorsed by the author/maintainer.

-Fred

On Apr 10, 2014, at 1:11 AM, Alan Antonuk <[hidden email]> wrote:

What version of SimpleAmqpClient are you using? The lines surrounding your change don't seem to match what is currently in the master branch of SimpleAmqpClient. I believe behavior you're seeing was addressed a while ago (see Issue #56). Please download the master branch and build from that, you will also need rabbitmq-c v0.4.1 or newer for this to work.

FYI: the patch you are suggesting using will likely cause undefined behavior. Because of the way rabbitmq-c's memory management works, the SimpleAmqpClient cannot call amqp_maybe_release_buffers() until it no longer holds any references to frames returned from amqp_simple_wait_frame(). Once amqp_maybe_release_buffers() (or amqp_maybe_release_buffers_on_channel()) any outstanding frames are considered freed and their use will lead to undefined behavior. SimpleAmqpClient maintains a list of frames that it has seen from the broker, in ChannelImpl::MaybeReleaseBuffersOnChannel it checks to see if there are any frames that it still has a reference to before calling amqp_maybe_release_buffers()

-Alan


On Wed, Apr 9, 2014 at 3:17 PM, Dushin Fred <[hidden email]> wrote:
That works for me, too.  Thanks, Abhay.

Alan, would you like a pull request?  Is there a timeline for folding this an the other recent fixes into master?  Anything I can do to help expedite?

-Fred

On Apr 9, 2014, at 4:54 AM, Abhay Rajure <[hidden email]> wrote:

Try this --

In File SimpleAmqpClient/src/ChannelImpl.cpp,
call amqp_maybe_release_buffers_on_channel() in ReturnChannel().

void ChannelImpl::ReturnChannel(amqp_chanel_t channel)
{
  +amqp_maybe_release_buffers_on_channel(m_connection, channel);
   m_free_channels.push(channel);
}


_______________________________________________
rabbitmq-discuss mailing list
[hidden email]
https://lists.rabbitmq.com/cgi-bin/mailman/listinfo/rabbitmq-discuss


_______________________________________________
rabbitmq-discuss mailing list
[hidden email]
https://lists.rabbitmq.com/cgi-bin/mailman/listinfo/rabbitmq-discuss


_______________________________________________
rabbitmq-discuss mailing list
[hidden email]
https://lists.rabbitmq.com/cgi-bin/mailman/listinfo/rabbitmq-discuss
Reply | Threaded
Open this post in threaded view
|

Re: rabbitmq-c memory leak?

alan.antonuk
Do you get the same problems building it off of the master branch?
On Thu, Apr 10, 2014 at 4:46 AM, Dushin Fred <[hidden email]> wrote:
Sorry, I should have been more clear.

The original issue I hit was from a build off the 2.3 tag (418f31f).  So the patch I applied was slightly different:

> git diff
diff --git a/src/ChannelImpl.cpp b/src/ChannelImpl.cpp
index 9749556..864502b 100644
--- a/src/ChannelImpl.cpp
+++ b/src/ChannelImpl.cpp
@@ -152,6 +152,7 @@ amqp_channel_t ChannelImpl::GetChannel()
 
 void ChannelImpl::ReturnChannel(amqp_channel_t channel)
 {
+       amqp_maybe_release_buffers_on_channel(m_connection, channel);
     m_channels.at(channel) = CS_Open;
     m_last_used_channel = channel;
 }

I fully respect that this may not be the "right" fix, but in my limited scenario (the sender.cpp program I posted off github), it does the trick.

I have done zero analysis of the right fix, but I'd be happy to crack open the code and look into it, if the root cause of the bug is not immediately evident to you.  Otherwise, if you have any thoughts, feel free to let me know.

And of course I would prefer (as I suspect many would) that the fix go into master, as this bug seems to effectively render the C++ client library unsuitable for production, and I would prefer not to maintain a fix that is not endorsed by the author/maintainer.

-Fred

On Apr 10, 2014, at 1:11 AM, Alan Antonuk <[hidden email]> wrote:

What version of SimpleAmqpClient are you using? The lines surrounding your change don't seem to match what is currently in the master branch of SimpleAmqpClient. I believe behavior you're seeing was addressed a while ago (see Issue #56). Please download the master branch and build from that, you will also need rabbitmq-c v0.4.1 or newer for this to work.

FYI: the patch you are suggesting using will likely cause undefined behavior. Because of the way rabbitmq-c's memory management works, the SimpleAmqpClient cannot call amqp_maybe_release_buffers() until it no longer holds any references to frames returned from amqp_simple_wait_frame(). Once amqp_maybe_release_buffers() (or amqp_maybe_release_buffers_on_channel()) any outstanding frames are considered freed and their use will lead to undefined behavior. SimpleAmqpClient maintains a list of frames that it has seen from the broker, in ChannelImpl::MaybeReleaseBuffersOnChannel it checks to see if there are any frames that it still has a reference to before calling amqp_maybe_release_buffers()

-Alan


On Wed, Apr 9, 2014 at 3:17 PM, Dushin Fred <[hidden email]> wrote:
That works for me, too.  Thanks, Abhay.

Alan, would you like a pull request?  Is there a timeline for folding this an the other recent fixes into master?  Anything I can do to help expedite?

-Fred

On Apr 9, 2014, at 4:54 AM, Abhay Rajure <[hidden email]> wrote:

Try this --

In File SimpleAmqpClient/src/ChannelImpl.cpp,
call amqp_maybe_release_buffers_on_channel() in ReturnChannel().

void ChannelImpl::ReturnChannel(amqp_chanel_t channel)
{
  +amqp_maybe_release_buffers_on_channel(m_connection, channel);
   m_free_channels.push(channel);
}


_______________________________________________
rabbitmq-discuss mailing list
[hidden email]
https://lists.rabbitmq.com/cgi-bin/mailman/listinfo/rabbitmq-discuss


_______________________________________________
rabbitmq-discuss mailing list
[hidden email]
https://lists.rabbitmq.com/cgi-bin/mailman/listinfo/rabbitmq-discuss

_______________________________________________
rabbitmq-discuss mailing list
[hidden email]
https://lists.rabbitmq.com/cgi-bin/mailman/listinfo/rabbitmq-discuss

_______________________________________________
rabbitmq-discuss mailing list
[hidden email]
https://lists.rabbitmq.com/cgi-bin/mailman/listinfo/rabbitmq-discuss
Reply | Threaded
Open this post in threaded view
|

Re: rabbitmq-c memory leak?

Dushin Fred
I am happy to report that by upgrading to RabbitMQ-c 0.5.0 and SimpleAmqpClient master (2e1b4e3), the leak has disappeared.

I apologize for the false alarm, though it does seem like the combination of SimpleAmqpClient 2.3 and RabbitMQ-c 0.4.0 brought about the issue.

Looking at the diffs after 2.3, I don't see any obvious culprits, but I am not intimately familiar with the code.

In any event, problem solved -- thanks, Alan!

-Fred

On Apr 10, 2014, at 9:21 AM, Alan Antonuk <[hidden email]> wrote:

Do you get the same problems building it off of the master branch?
On Thu, Apr 10, 2014 at 4:46 AM, Dushin Fred <[hidden email]> wrote:
Sorry, I should have been more clear.

The original issue I hit was from a build off the 2.3 tag (418f31f).  So the patch I applied was slightly different:

> git diff
diff --git a/src/ChannelImpl.cpp b/src/ChannelImpl.cpp
index 9749556..864502b 100644
--- a/src/ChannelImpl.cpp
+++ b/src/ChannelImpl.cpp
@@ -152,6 +152,7 @@ amqp_channel_t ChannelImpl::GetChannel()
 
 void ChannelImpl::ReturnChannel(amqp_channel_t channel)
 {
+       amqp_maybe_release_buffers_on_channel(m_connection, channel);
     m_channels.at(channel) = CS_Open;
     m_last_used_channel = channel;
 }

I fully respect that this may not be the "right" fix, but in my limited scenario (the sender.cpp program I posted off github), it does the trick.

I have done zero analysis of the right fix, but I'd be happy to crack open the code and look into it, if the root cause of the bug is not immediately evident to you.  Otherwise, if you have any thoughts, feel free to let me know.

And of course I would prefer (as I suspect many would) that the fix go into master, as this bug seems to effectively render the C++ client library unsuitable for production, and I would prefer not to maintain a fix that is not endorsed by the author/maintainer.

-Fred

On Apr 10, 2014, at 1:11 AM, Alan Antonuk <[hidden email]> wrote:

What version of SimpleAmqpClient are you using? The lines surrounding your change don't seem to match what is currently in the master branch of SimpleAmqpClient. I believe behavior you're seeing was addressed a while ago (see Issue #56). Please download the master branch and build from that, you will also need rabbitmq-c v0.4.1 or newer for this to work.

FYI: the patch you are suggesting using will likely cause undefined behavior. Because of the way rabbitmq-c's memory management works, the SimpleAmqpClient cannot call amqp_maybe_release_buffers() until it no longer holds any references to frames returned from amqp_simple_wait_frame(). Once amqp_maybe_release_buffers() (or amqp_maybe_release_buffers_on_channel()) any outstanding frames are considered freed and their use will lead to undefined behavior. SimpleAmqpClient maintains a list of frames that it has seen from the broker, in ChannelImpl::MaybeReleaseBuffersOnChannel it checks to see if there are any frames that it still has a reference to before calling amqp_maybe_release_buffers()

-Alan


On Wed, Apr 9, 2014 at 3:17 PM, Dushin Fred <[hidden email]> wrote:
That works for me, too.  Thanks, Abhay.

Alan, would you like a pull request?  Is there a timeline for folding this an the other recent fixes into master?  Anything I can do to help expedite?

-Fred

On Apr 9, 2014, at 4:54 AM, Abhay Rajure <[hidden email]> wrote:

Try this --

In File SimpleAmqpClient/src/ChannelImpl.cpp,
call amqp_maybe_release_buffers_on_channel() in ReturnChannel().

void ChannelImpl::ReturnChannel(amqp_chanel_t channel)
{
  +amqp_maybe_release_buffers_on_channel(m_connection, channel);
   m_free_channels.push(channel);
}


_______________________________________________
rabbitmq-discuss mailing list
[hidden email]
https://lists.rabbitmq.com/cgi-bin/mailman/listinfo/rabbitmq-discuss


_______________________________________________
rabbitmq-discuss mailing list
[hidden email]
https://lists.rabbitmq.com/cgi-bin/mailman/listinfo/rabbitmq-discuss

_______________________________________________
rabbitmq-discuss mailing list
[hidden email]
https://lists.rabbitmq.com/cgi-bin/mailman/listinfo/rabbitmq-discuss
_______________________________________________
rabbitmq-discuss mailing list
[hidden email]
https://lists.rabbitmq.com/cgi-bin/mailman/listinfo/rabbitmq-discuss

_______________________________________________
rabbitmq-discuss mailing list
[hidden email]
https://lists.rabbitmq.com/cgi-bin/mailman/listinfo/rabbitmq-discuss
Reply | Threaded
Open this post in threaded view
|

Re: rabbitmq-c memory leak?

Abhay Rajure
fred@... <fred@...> writes:

>
>
> I am happy to report that by upgrading to RabbitMQ-c 0.5.0 and
SimpleAmqpClient master (2e1b4e3), the leak has disappeared.
>
> I apologize for the false alarm, though it does seem like the combination
of SimpleAmqpClient 2.3 and RabbitMQ-c 0.4.0 brought about the issue.
>
> Looking at the diffs after 2.3, I don't see any obvious culprits, but I am
not intimately familiar with the code.
>
> In any event, problem solved -- thanks, Alan!-Fred
>

Thanks Fred for the update!

I can confirm as well that with the latest master and the leak seems to have
disappeared.

Thanks Alan & Fred!

-Abhay


_______________________________________________
rabbitmq-discuss mailing list
[hidden email]
https://lists.rabbitmq.com/cgi-bin/mailman/listinfo/rabbitmq-discuss
Reply | Threaded
Open this post in threaded view
|

Re: rabbitmq-c memory leak?

Abhay Rajure
In reply to this post by alan.antonuk
Alan Antonuk <alan.antonuk@...> writes:
 
> On Apr 10, 2014, at 1:11 AM, Alan Antonuk
<[hidden email]> wrote:
>
>
> What version of SimpleAmqpClient are you using? The lines surrounding your
change don't seem to match what is currently in the master branch of
SimpleAmqpClient. I believe behavior you're seeing was addressed a while ago
(see Issue #56). Please download the master branch and build from that, you
will also need rabbitmq-c v0.4.1 or newer for this to work.
>
>
>
> -Alan
>

Hi Alan,
 Can you recommend a specific tag we can use from the master that addresses
this memory leak issue you've mentioned (Issue #56)?

 Or is it safe to use the latest from master (unreleased) version?

Thanks,
Abhay


_______________________________________________
rabbitmq-discuss mailing list
[hidden email]
https://lists.rabbitmq.com/cgi-bin/mailman/listinfo/rabbitmq-discuss
Reply | Threaded
Open this post in threaded view
|

Re: rabbitmq-c memory leak?

alan.antonuk
The master branch in general pretty safe to use. I do make an effort to have whatever is in the published master branch be stable. Feature branches are up for grabs and likely unstable until merged.

-Alan


On Thu, Apr 10, 2014 at 11:51 AM, Abhay Rajure <[hidden email]> wrote:
Alan Antonuk <alan.antonuk@...> writes:

> On Apr 10, 2014, at 1:11 AM, Alan Antonuk
<[hidden email]> wrote:
>
>
> What version of SimpleAmqpClient are you using? The lines surrounding your
change don't seem to match what is currently in the master branch of
SimpleAmqpClient. I believe behavior you're seeing was addressed a while ago
(see Issue #56). Please download the master branch and build from that, you
will also need rabbitmq-c v0.4.1 or newer for this to work.
>
>
>
> -Alan
>

Hi Alan,
 Can you recommend a specific tag we can use from the master that addresses
this memory leak issue you've mentioned (Issue #56)?

 Or is it safe to use the latest from master (unreleased) version?

Thanks,
Abhay


_______________________________________________
rabbitmq-discuss mailing list
[hidden email]
https://lists.rabbitmq.com/cgi-bin/mailman/listinfo/rabbitmq-discuss


_______________________________________________
rabbitmq-discuss mailing list
[hidden email]
https://lists.rabbitmq.com/cgi-bin/mailman/listinfo/rabbitmq-discuss