You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@qpid.apache.org by Tony Ercolano <to...@microsoft.com> on 2015/04/17 22:54:19 UTC
pn_messenger_free semantics ...
I have two questions:
1) Is it safe to do a pn_messenger_free on a messenger that has NOT been used as an argument to pn_messenger_stop?
2) Is it safe to do a pn_messenger_free on a messenger that HAS been used as an argument to pn_messenger_stop BUT pn_messenger_stopped with that same argument has only returned false.
NOTE: Assume that the messenger was used as an argument to pn_messenger_set_blocking(messenger, false) previous to the stop/stopped/free above.
Thank you for your thoughts,
Tony
RE: pn_messenger_free semantics ...
Posted by Tony Ercolano <to...@microsoft.com>.
The call stack I had sent was .8. This call stack is .9
qpid-protond.dll!pn_object_new(const pn_class_t * clazz, unsigned int size) Line 203 C++
qpid-protond.dll!pn_class_new(const pn_class_t * clazz, unsigned int size) Line 63 C++
qpid-protond.dll!pn_selectable_new() Line 93 C++
qpid-protond.dll!pn_selectable() Line 98 C++
qpid-protond.dll!pn_connection_ctx(pn_messenger_t * messenger, pn_connection_t * conn, unsigned int sock, const char * scheme, const char * user, const char * pass, const char * host, const char * port, pn_listener_ctx_t * lnr) Line 451 C++
qpid-protond.dll!pn_messenger_connection(pn_messenger_t * messenger, unsigned int sock, const char * scheme, char * user, char * pass, char * host, char * port, pn_listener_ctx_t * lnr) Line 1076 C++
qpid-protond.dll!pn_messenger_resolve(pn_messenger_t * messenger, const char * address, char * * name) Line 1636 C++
qpid-protond.dll!pn_messenger_link(pn_messenger_t * messenger, const char * address, bool sender, unsigned int timeout) Line 1679 C++
qpid-protond.dll!pn_messenger_source(pn_messenger_t * messenger, const char * source, unsigned int timeout) Line 1740 C++
qpid-protond.dll!pn_messenger_subscribe_ttl(pn_messenger_t * messenger, const char * source, unsigned int timeout) Line 1774 C++
qpid-protond.dll!pn_messenger_subscribe(pn_messenger_t * messenger, const char * source) Line 1751 C++
sendtelemetryasync.exe!protonMessengerInit(CLIENT_STATE_TAG * clientState) Line 219 C
-----Original Message-----
From: Rafael Schloming [mailto:rhs@alum.mit.edu]
Sent: Saturday, April 18, 2015 4:42 AM
To: users@qpid.apache.org
Subject: Re: pn_messenger_free semantics ...
What version are you using?
--Rafael
On Fri, Apr 17, 2015 at 7:02 PM, Tony Ercolano <to...@microsoft.com>
wrote:
> On windows I'm using some rtl code to find any memory leaks.
>
> I have an app that creates a messenger. When the app is finished it
> simply calls pn_messenger_free.
> I then not long after the return from pn_messenger_free I call the rtl
> code that checks what has been mallo'c but not freed.
>
> It pointed to memory that was allocated with the following call stack:
> qpid-protond.dll!pn_object_new(const pn_class_t * clazz, unsigned
> int size) Line 203 C++
> qpid-protond.dll!pn_class_new(const pn_class_t * clazz, unsigned
> int size) Line 63 C++
> qpid-protond.dll!pni_selectable(long (pn_selectable_t *) *
> capacity, long (pn_selectable_t *) * pending, __int64 (pn_selectable_t
> *) * deadline, void (pn_selectable_t *) * readable, void
> (pn_selectable_t *) * writable, void (pn_selectable_t *) * expired, void (pn_selectable_t *) *
> finalize) Line 94 C++
> qpid-protond.dll!pn_connection_ctx(pn_messenger_t * messenger,
> pn_connection_t * conn, unsigned int sock, const char * scheme, const
> char
> * user, const char * pass, const char * host, const char * port,
> pn_listener_ctx_t * lnr) Line 468 C++
> qpid-protond.dll!pn_messenger_connection(pn_messenger_t *
> messenger, unsigned int sock, const char * scheme, char * user, char *
> pass, char * host, char * port, pn_listener_ctx_t * lnr) Line 1108 C++
> qpid-protond.dll!pn_messenger_resolve(pn_messenger_t * messenger,
> const char * address, char * * name) Line 1662 C++
> qpid-protond.dll!pn_messenger_link(pn_messenger_t * messenger,
> const char * address, bool sender, unsigned int timeout) Line 1704 C++
> qpid-protond.dll!pn_messenger_source(pn_messenger_t * messenger,
> const char * source, unsigned int timeout) Line 1765 C++
> qpid-protond.dll!pn_messenger_subscribe_ttl(pn_messenger_t *
> messenger, const char * source, unsigned int timeout) Line 1799 C++
> qpid-protond.dll!pn_messenger_subscribe(pn_messenger_t *
> messenger, const char * source) Line 1776 C++
> sendtelemetryasync.exe!protonMessengerInit(CLIENT_STATE_TAG *
> clientState) Line 183
>
> Thoughts?
>
> -----Original Message-----
> From: Rafael Schloming [mailto:rhs@alum.mit.edu]
> Sent: Friday, April 17, 2015 2:14 PM
> To: users@qpid.apache.org
> Subject: Re: pn_messenger_free semantics ...
>
> On Fri, Apr 17, 2015 at 4:54 PM, Tony Ercolano
> <to...@microsoft.com>
> wrote:
>
> > I have two questions:
> >
> >
> > 1) Is it safe to do a pn_messenger_free on a messenger that has NOT
> > been used as an argument to pn_messenger_stop?
> >
> >
> > 2) Is it safe to do a pn_messenger_free on a messenger that HAS been
> > used as an argument to pn_messenger_stop BUT pn_messenger_stopped
> > with that same argument has only returned false.
> >
> >
> > NOTE: Assume that the messenger was used as an argument to
> > pn_messenger_set_blocking(messenger, false) previous to the
> > stop/stopped/free above.
> >
> > Thank you for your thoughts,
> > Tony
> >
>
> Both should be safe in the programming sense, i.e. neither one should
> leak memory or result in corrupted state or anything like that. You
> could of course have remote parties observe aborted connections, but I
> assume given your question that you don't consider that to be unsafe.
>
> --Rafael
>
Re: pn_messenger_free semantics ...
Posted by Rafael Schloming <rh...@alum.mit.edu>.
What version are you using?
--Rafael
On Fri, Apr 17, 2015 at 7:02 PM, Tony Ercolano <to...@microsoft.com>
wrote:
> On windows I'm using some rtl code to find any memory leaks.
>
> I have an app that creates a messenger. When the app is finished it
> simply calls pn_messenger_free.
> I then not long after the return from pn_messenger_free I call the rtl
> code that checks what has been mallo'c but not freed.
>
> It pointed to memory that was allocated with the following call stack:
> qpid-protond.dll!pn_object_new(const pn_class_t * clazz, unsigned
> int size) Line 203 C++
> qpid-protond.dll!pn_class_new(const pn_class_t * clazz, unsigned
> int size) Line 63 C++
> qpid-protond.dll!pni_selectable(long (pn_selectable_t *) *
> capacity, long (pn_selectable_t *) * pending, __int64 (pn_selectable_t *) *
> deadline, void (pn_selectable_t *) * readable, void (pn_selectable_t *) *
> writable, void (pn_selectable_t *) * expired, void (pn_selectable_t *) *
> finalize) Line 94 C++
> qpid-protond.dll!pn_connection_ctx(pn_messenger_t * messenger,
> pn_connection_t * conn, unsigned int sock, const char * scheme, const char
> * user, const char * pass, const char * host, const char * port,
> pn_listener_ctx_t * lnr) Line 468 C++
> qpid-protond.dll!pn_messenger_connection(pn_messenger_t *
> messenger, unsigned int sock, const char * scheme, char * user, char *
> pass, char * host, char * port, pn_listener_ctx_t * lnr) Line 1108 C++
> qpid-protond.dll!pn_messenger_resolve(pn_messenger_t * messenger,
> const char * address, char * * name) Line 1662 C++
> qpid-protond.dll!pn_messenger_link(pn_messenger_t * messenger,
> const char * address, bool sender, unsigned int timeout) Line 1704 C++
> qpid-protond.dll!pn_messenger_source(pn_messenger_t * messenger,
> const char * source, unsigned int timeout) Line 1765 C++
> qpid-protond.dll!pn_messenger_subscribe_ttl(pn_messenger_t *
> messenger, const char * source, unsigned int timeout) Line 1799 C++
> qpid-protond.dll!pn_messenger_subscribe(pn_messenger_t *
> messenger, const char * source) Line 1776 C++
> sendtelemetryasync.exe!protonMessengerInit(CLIENT_STATE_TAG *
> clientState) Line 183
>
> Thoughts?
>
> -----Original Message-----
> From: Rafael Schloming [mailto:rhs@alum.mit.edu]
> Sent: Friday, April 17, 2015 2:14 PM
> To: users@qpid.apache.org
> Subject: Re: pn_messenger_free semantics ...
>
> On Fri, Apr 17, 2015 at 4:54 PM, Tony Ercolano <to...@microsoft.com>
> wrote:
>
> > I have two questions:
> >
> >
> > 1) Is it safe to do a pn_messenger_free on a messenger that has NOT
> > been used as an argument to pn_messenger_stop?
> >
> >
> > 2) Is it safe to do a pn_messenger_free on a messenger that HAS been
> > used as an argument to pn_messenger_stop BUT pn_messenger_stopped with
> > that same argument has only returned false.
> >
> >
> > NOTE: Assume that the messenger was used as an argument to
> > pn_messenger_set_blocking(messenger, false) previous to the
> > stop/stopped/free above.
> >
> > Thank you for your thoughts,
> > Tony
> >
>
> Both should be safe in the programming sense, i.e. neither one should leak
> memory or result in corrupted state or anything like that. You could of
> course have remote parties observe aborted connections, but I assume given
> your question that you don't consider that to be unsafe.
>
> --Rafael
>
RE: pn_messenger_free semantics ...
Posted by Tony Ercolano <to...@microsoft.com>.
On windows I'm using some rtl code to find any memory leaks.
I have an app that creates a messenger. When the app is finished it simply calls pn_messenger_free.
I then not long after the return from pn_messenger_free I call the rtl code that checks what has been mallo'c but not freed.
It pointed to memory that was allocated with the following call stack:
qpid-protond.dll!pn_object_new(const pn_class_t * clazz, unsigned int size) Line 203 C++
qpid-protond.dll!pn_class_new(const pn_class_t * clazz, unsigned int size) Line 63 C++
qpid-protond.dll!pni_selectable(long (pn_selectable_t *) * capacity, long (pn_selectable_t *) * pending, __int64 (pn_selectable_t *) * deadline, void (pn_selectable_t *) * readable, void (pn_selectable_t *) * writable, void (pn_selectable_t *) * expired, void (pn_selectable_t *) * finalize) Line 94 C++
qpid-protond.dll!pn_connection_ctx(pn_messenger_t * messenger, pn_connection_t * conn, unsigned int sock, const char * scheme, const char * user, const char * pass, const char * host, const char * port, pn_listener_ctx_t * lnr) Line 468 C++
qpid-protond.dll!pn_messenger_connection(pn_messenger_t * messenger, unsigned int sock, const char * scheme, char * user, char * pass, char * host, char * port, pn_listener_ctx_t * lnr) Line 1108 C++
qpid-protond.dll!pn_messenger_resolve(pn_messenger_t * messenger, const char * address, char * * name) Line 1662 C++
qpid-protond.dll!pn_messenger_link(pn_messenger_t * messenger, const char * address, bool sender, unsigned int timeout) Line 1704 C++
qpid-protond.dll!pn_messenger_source(pn_messenger_t * messenger, const char * source, unsigned int timeout) Line 1765 C++
qpid-protond.dll!pn_messenger_subscribe_ttl(pn_messenger_t * messenger, const char * source, unsigned int timeout) Line 1799 C++
qpid-protond.dll!pn_messenger_subscribe(pn_messenger_t * messenger, const char * source) Line 1776 C++
sendtelemetryasync.exe!protonMessengerInit(CLIENT_STATE_TAG * clientState) Line 183
Thoughts?
-----Original Message-----
From: Rafael Schloming [mailto:rhs@alum.mit.edu]
Sent: Friday, April 17, 2015 2:14 PM
To: users@qpid.apache.org
Subject: Re: pn_messenger_free semantics ...
On Fri, Apr 17, 2015 at 4:54 PM, Tony Ercolano <to...@microsoft.com>
wrote:
> I have two questions:
>
>
> 1) Is it safe to do a pn_messenger_free on a messenger that has NOT
> been used as an argument to pn_messenger_stop?
>
>
> 2) Is it safe to do a pn_messenger_free on a messenger that HAS been
> used as an argument to pn_messenger_stop BUT pn_messenger_stopped with
> that same argument has only returned false.
>
>
> NOTE: Assume that the messenger was used as an argument to
> pn_messenger_set_blocking(messenger, false) previous to the
> stop/stopped/free above.
>
> Thank you for your thoughts,
> Tony
>
Both should be safe in the programming sense, i.e. neither one should leak memory or result in corrupted state or anything like that. You could of course have remote parties observe aborted connections, but I assume given your question that you don't consider that to be unsafe.
--Rafael
Re: pn_messenger_free semantics ...
Posted by Rafael Schloming <rh...@alum.mit.edu>.
On Fri, Apr 17, 2015 at 4:54 PM, Tony Ercolano <to...@microsoft.com>
wrote:
> I have two questions:
>
>
> 1) Is it safe to do a pn_messenger_free on a messenger that has NOT
> been used as an argument to pn_messenger_stop?
>
>
> 2) Is it safe to do a pn_messenger_free on a messenger that HAS been
> used as an argument to pn_messenger_stop BUT pn_messenger_stopped with that
> same argument has only returned false.
>
>
> NOTE: Assume that the messenger was used as an argument to
> pn_messenger_set_blocking(messenger, false) previous to the
> stop/stopped/free above.
>
> Thank you for your thoughts,
> Tony
>
Both should be safe in the programming sense, i.e. neither one should leak
memory or result in corrupted state or anything like that. You could of
course have remote parties observe aborted connections, but I assume given
your question that you don't consider that to be unsafe.
--Rafael